(Лекция 2)
Проектирование автоматизированных систем (АС)
Методологии и технологии проектирования АС. Общие понятия.
Большая советская энциклопедия - Методология (от метод и... логия), учение о структуре, логической организации, методах и средствах деятельности.
Методология - система наиболее общих принципов, положений и методов, составляющих основу той или иной науки (проектирования АС).
Технология - это методы и средства (CASE-средства), используемые для проектирования АС
Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства
Методологии и технологии составляют основу проекта любой АС.
Метод (от греч. — «способ») — систематизированная совокупность шагов, действий, которые необходимо предпринять, чтобы решить определенную задачу или достичь определенной цели.
Методика (гр. methodike) - совокупность способов целесообразного проведения какой-либо работы, реализации метода, технические приемы реализации метода, конкретное воплощение метода
Технология проектирования определяется как совокупность трех составляющих:
- шаговой процедуры, определяющей последовательность технологических операций проектирования;
- критериев и правил, используемых для оценки результатов выполнения технологических операций;
- нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Используемая для проектирования, разработки и сопровождения АС ТЕХНОЛОГИЯ должна удовлетворять следующим требованиям:
- поддерживать полный ЖЦ АС;
- обеспечивать гарантированное достижение целей разработки АС с заданным качеством и в установленное время;
- обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей).
Профиль автоматизированной системы представляет собой подмножества и/или комбинации базовых стандартов информационных технологий, необходимые для реализации заданных наборов функций.
Стандарт - эталон, модель, принимаемые за исходные для сравнения с ними других объектов, совокупность нормативно-технических документов, описывающих эталон.
Этапы жизненного цикла АС
Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.
Жизненный цикл автоматизированной системы представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного её изъятия из эксплуатации.
Методология проектирования информационных систем описывает жизненный цикла АС (модель ЖЦ) как некоторую последовательность стадий и выполняемых на них процессов.
Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются с системой
При этом различают две основные формальные модели ЖЦ АС:
- каскадную (последовательную);
- спиральную (итерационную).
Этапы классической модели жизненного цикла АС :
1 Формирование требований
2 Проектирование
3 Реализация
4 Тестирование
5 Ввод в действие
6 Эксплуатация и сопровождение
Для каждого этапа определяются состав и последовательность выполняемых работ (процессов, процедур) получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д.
Стандарты и методологии, регламентирующие этапы ЖЦ АС
Реальное применение любой технологии проектирования, разработки и сопровождения АС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта.
К таким стандартам относятся следующие:
- стандарт проектирования;
- стандарт оформления проектной документации;
- стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
- правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
- требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
- механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
- комплектность, состав и структуру документации на каждой стадии проектирования;
- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),
- правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
- требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
- правила использования клавиатуры и мыши;
- правила оформления текстов помощи;
- перечень стандартных сообщений;
- правила обработки реакции пользователя и др.
Стандарты и методологии, регламентирующие ЖЦ АС
(в некоторых случаях и процессы разработки системы)
1 Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования).
Шаги процесса BSP можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике:
- получить поддержку высшего руководства;
- определить процессы предприятия;
- определить классы данных;
- провести интервью;
- обработать и организовать данные интервью.
Среди наиболее известных стандартов можно выделить следующие:
2 ISO/IEC 12207:1995
Российский аналог - ГОСТ Р ИСО/МЭК 12207-99
Стандарт на процессы и организацию жизненного цикла АС. Распространяется на все виды заказных систем. Стандарт не содержит описания фаз, стадий и этапов, а описывает процессы, которые соответствуют различным этапам ЖЦ АС:
Основные:
- приобретение, поставка;
- разработка;
- эксплуатация;
- сопровождение.
Вспомогательные:
- документирование;
- управление конфигурацией;
- верификация;
- аттестация;
- совместная оценка;
- аудит;
- разрешение проблем.
Организационные:
- управление;
- создание инфраструктуры;
- усовершенствование;
- обучение персонала.
3 ГОСТ 34.601-90
Распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла и включают в себя:
- формирование требований к АС;
- разработка концепции АС;
- техническое задание;
- эскизный проект;
- технический проект;
- рабочая документация;
- ввод в действие;
- сопровождение АС.
4. Custom Development Method (CDM)
Это методика, используется корпорацией Oracle по разработке информационных систем. Представляет собой технологический материал, рассчитанных на использование в проектах с применением СУБД Oracle. CDM применяется при использовании классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.
Один процесс может соответствовать нескольким этапам ЖЦ. И одному этапу ЖЦ может соответствовать несколько процессов, выполняемых параллельно. Методика выделяет следующие процессы:
- постановка задачи;
- исследование существующих систем;
- определение структуры системы (технической и программной);
- проектирование и построение БД;
- преобразование данных;
- документирование;
- тестирование;
- обучение;
- внедрение;
- поддержка и сопровождение.
5. Rational Unified Process (RUP)
Методика предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы.
Если после этого работа над проектом не прекращается, то система продолжает развиваться и снова минует те же фазы.
Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML. Процессы привязаны к использованию конкретных средств моделирования, поддерживающих технологию UML, а так же к конкретной технологии проектирования и разработки (объектно-ориентированный анализ, объектноориентированное программирование).
Суть RUP - создание и сопровождение моделей, а не бумажных документов.
6. Microsoft Solution Framework (MSF)
Методика сходна с RUP, так же включает четыре фазы: анализ,
проектирование, разработка, стабилизация. Я
Является итерационной, предполагает использование объектно -ориентированного моделирования.
MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Бизнес-приложение - это информационная система, ориентированная на автоматизацию определенных бизнес-процессов предприятия. Пример бизнес-приложений - информационные системы, реализованные на платформе 1С: «Предприятие», «Склад» и др.
7. Методология RAD
Это методология быстрой разработки приложений RAD (Rapid Application Development), реализующая подход к разработке АС в рамках спиральной модели ЖЦ и получившая в последнее время широкое распространение
Жизненный цикл АС соответствии с методологией RAD состоит из четырех
фаз:
- анализ и планирование требований;
- проектирование;
- построение;
- внедрение.
Требования методологии:
- небольшая команда разработчиков (от 2 до 10 человек);
- короткий, но тщательно проработанный производственный график (от 2 до 6
мес.);
- повторяющийся цикл, при котором разработчики, по мере того, как проект начинает обретать форму, запрашивают и реализуют в системе требования, полученные через взаимодействие с заказчиком.
Методология предполагает использование CASE-средств для быстрого получения работающих прототипов приложений.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Методология RAD неприменима для построения АС, предназначенных для сложных расчетных программ, операционных систем или программ управления
космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Ограничения методологии RAD
Несмотря на все свои достоинства, методология RAD (как, впрочем, и любая другая методология), не может претендовать на универсальность. Ее применение наиболее эффективно при создании сравнительно небольших систем, разрабатываемых для конкретного заказчика.
При разработке же типовых систем, не являющихся законченным продуктом, а представляющих собой совокупность типовых элементов информационной системы, большое значение имеют такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Это связано с тем, что типовые системы обычно централизованно сопровождаются и могут адаптироваться к различным программноаппаратным платформам, системам управления базами данных, коммуникационным средствам, а также интегрироваться с существующими разработками. Поэтому для такого рода проектов необходим высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD не подходит для создания не только типовых информационных систем, но и сложных расчетных программ, операционных систем и программ управления сложными инженерно-техническими объектами, то есть программ, требующих написания большого объема уникального кода.
Методология RAD не может быть использована для разработки приложений, в которых интерфейс пользователя является вторичным, то есть отсутствует наглядное определение логики работы системы. Примерами таких приложений могут служить приложения реального времени, драйверы или службы.
Совершенно неприемлема методология RAD для разработки систем, от которых зависит безопасность людей, например, систем управления транспортом или атомными электростанциями. Это обусловлено тем, что итеративный подход, являющийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособными, что в данном случае может привести к серьезнейшим катастрофам.
8. Методология функционального моделирования SADT
Методология Structural Analysis and Design Technique (SADT) разработана Дугласом Россом, далее получила дальнейшее развитие. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области (рисунок). Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Рисунок - Пример функциональной модели
Методология SADT может использоваться для моделирования широкого круга информационных систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
9. Методология DFD
В основе данной методологии лежит построение модели анализируемой ИС -проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD - Data Flow Diagrams), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю (рисунок). Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы АС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня.
Рисунок - Пример диаграммы потоков данных
Основными компонентами диаграмм потоков данных являются: внешние сущности; системы/подсистемы; процессы; накопители данных; потоки данных.
Первым шагом при построении иерархии ДПД является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс. Для сложных ИС строится иерархия контекстных диаграмм.
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы.
10. Методология ARIS
Методология позволяет отразить бизнес-процессы предприятия. Концепция Архитектура Интегрированных Информационных Систем - ARIS (Architecture of Integrated Information Systems) разработана профессором А.В. Шеером (Scheer).
Эта концепция имеет два основных преимущества:
• позволяет выбрать методы и интегрировать их, опираясь на основные особенности моделируемого объекта;
• служит базой для управления сложными проектами, поскольку благодаря структурным элементам содержит встроенные модели процедур для разработки интегрированных информационных систем.
Такая архитектура дает возможность вводить в применяемые методы элементы стандартизации. Новые методы моделирования, а также те, в основе которых лежит концепция ARIS, были интегрированы в рамках архитектуры, что позволило создать комплексный метод моделирования бизнес-процессов.
Архитектура ARIS явилась основой ARIS Toolset - инструментальной среды, разработанной компанией IDS Scheer AG. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. В ARIS имеется мощная репрезентативная графика, что делает модели особенно удобными для представления руководству.
Среди большого количества возможных методов описания, используемых ARIS, выделяют следующие:
- EPC (event-driven process chain) — метод описания процессов, нашедший применение в системе SAP R/3;
- ERM (Entity Relationship Model) — модель сущность-связь для описания структуры данных;
- UML (Unified Modeling Language) — объектно-ориентированный язык моделирования.
Концепция ARIS основана на идее интеграции, которая является составной частью комплексного анализа бизнес-процессов. Первый шаг при создании архитектуры состоит в разработке модели бизнес-процесса, описывающей все его основные функции. Полученная таким образом чрезвычайно сложная модель разделится на подмодели, или типы моделей, в соответствии с типами представлений. Это позволяет существенно снизить степень ее сложности.
Содержимое типов моделей может быть описано методами, предназначенными для конкретного типа представления. Многочисленные взаимосвязи между типами моделей при этом не учитываются. Впоследствии эти взаимосвязи инкорпорируются в общую модель для анализа всего процесса без какой-либо избыточности.
Архитектура ARIS создает основу для разработки и оптимизации интегрированных информационных систем, а также для описания их реализации. Выбор уровней и типов описаний формирует архитектуру ARIS, которая используется в качестве модели для построения процессов, связанных с управлением бизнесом, их анализа и оценки.
11 Методика Захмана
Джон Захман - один из наиболее интересных специалистов, занимающихся теорией в области разработки архитектуры информационных систем, входит в совет Международной ассоциации по управлению данными (Data Administration Management Association), участвует в издании журнала Data Management Review.
Захман предлагает признать, что компьютеры во всех их ипостасях есть всего лишь исполнительные элементы. Сами же по себе они ни архитектуры, ни системы не образуют. И архитектура, и система могут сложиться только в результате совместной деятельности всех участников процесса, в том числе заказчика АИС, проектировщика и исполнителя. Методика, предложенная Захманом, позволяет свести сложные архитектурные проблемы информационных систем к ответам на простые вопросы:
- что лежит в основе деятельности предприятия в рамках решаемой задачи автоматизации (data);
- как это делается (function);
- где происходят процессы обработки информации (network);
- кто выполняет процессы обработки информации (people);
- когда выполняется тот или иной процесс (time);
- почему эти процессы выполняются (motivation).
Захман сделал одну из немногочисленных попыток хоть как-то систематизировать подходы к созданию корпоративных информационных систем. Он создал таблицу для моделирования архитектуры, получившую признание под именем Zachman Framework. Впервые таблица была предложена в 1987 году, во второй же своей редакции она появилась в 1992 году. Долгое время таблица Захмана оставалась инструментом для бумажного моделирования, в настоящее время появились автоматизированные реализации таблицы на основе языка XML.
Таблица состоит из шести столбцов и шести строк. Каждый из столбцов отвечает на один из поставленных выше вопросов: что, как, где, кто, когда, зачем. Создание системы по Захману есть совокупность процедур, состоящих из ответов на перечисленные вопросы, на шести уровнях, каждому из которых соответствует строка:
- намерение (scope). Документы, составляемые на этом уровне как можно менее техничны, от них не требуется полнота. Желательно, чтобы на таком глобальном уровне проектированием занимались специалисты, не являющиеся ни исполнителями, ни владельцами будущей системы.
- модель предприятия (Enterprise Model). На этом уровне описывается функциональность в понимании заказчика.
- разработка модели системы (system model). Это и есть собственно работа архитектора, которая позволяет совместить представления заказчика с глобальным видением проблемы.
- разработка технологической модели (technology model). Привязка архитектуры к определенным аппаратным и программным средствам.
- компоненты (components). Распределение работ между ними.
- оценка функционирования (functioning system). По завершении всех предыдущих этапов пользователь может соотнести полученное с желаемым и внести изменения.
12Extreme Programming (XP)
Методология экстремального программирования является самой новой среди рассматриваемых, сформировалось в 1996 году. В основе методологии лежит командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке АС.
Разработка ведется с использованием последовательно дорабатываемых прототипов (готовый упрощенный вариант системы с заданным набором функций). Для методологии характерен отказ от предварительного проектирования, от техник проектирования (например, UML), их принципов. Незачем беспокоиться о проектировании, достаточно внимательно "вслушиваться" в свой код, и проектирование образуется само собой. Большая роль отводится тестированию.
Выбранный стандарт или методология определяет, с помощью каких средств моделирования, в каком объеме будут формализованы требования к разрабатываемой информационной системе.
В рамках курсового проекта будут выполняться процедуры, соответствующие классической модели ЖЦ АИС (выделены жирным шрифтом):
1 Формирование требований
2 Проектирование
3 Реализация
4 Тестирование
5 Ввод в действие
6 Эксплуатация и сопровождение
Опыт разработки крупных АС показывает, что для повышения эффективности работ необходимо:
1. Разбить проект на отдельные слабо связанные по данным и функциям подсистемы.
2. Обеспечить реализацию подсистем отдельными группами специалистов, (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей
3. Обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций
4. Обеспечивать минимальное время получения работоспособной АС. Речь идет не о сроках готовности всей АС, а о сроках реализации отдельных подсистем. Реализация АС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам.
5. Предусмотреть возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта.
6. Обеспечивать независимость выполняемых проектных решений от средств реализации АС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования).
7. Поддерживатьсогласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Скачать лекцию:
Пароль на архив: privetstudent.com