Министерство науки и высшего образования Российской Федерации
Дальневосточный федеральный университет
Школа естественных наук
А.И. Сухомлинов
АНАЛИЗ И ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ СИСТЕМ
Учебное пособие
2-е издание,
исправленное и дополненное
Для студентов, обучающихся по направлению
09.03.03. «Прикладная информатика»
Владивосток
2021
© Сухомлинов А.И., 2016
© Сухомлинов А.И., 2021, с изменениями
© Оформление. ФГАОУ ВО ДВФУ, 2021
ISBN 978-5-7444-5003-8
УДК 681.3.061(075.8)
ББК 32.973-02я73
Рецензенты:
А.А. Дыда, д-р техн. наук, профессор, профессор кафедры
автоматических и информационных систем МГУ им. адм. Г.И. Невельского;
Е.А. Голенков, канд. техн. наук, заведующий отделом
Института автоматики и процессов управления ДВО РАН
Сухомлинов, А.И. Анализ и проектирование информационных систем : учебное
пособие : для студентов, обучающихся по направлению 09.03.03. «Прикладная
информатика» / А.И. Сухомлинов. – 2-е издание, испр. и доп. – Владивосток : Издательство Дальневосточного федерального университета, 2021. – 1 CD-ROM ; [360 с.]. –
Загл. с титул. экр. – ISBN 978-5-7444-5003-8. – Текст. Изображения : электронные.
Пособие представляет фундаментальные основы разработки информационных систем. Комплексно рассматриваются вопросы архитектуры, методологий, принципов
разработки, стратегического планирования, анализа и проектирования информационных систем. Описываются фреймворк архитектуры информационной системы Джона
Захмана, методологии разработки информационных систем SSADM, Information
Engineering и Merise, а также методы моделирования компонентов систем, включая
функции, трудовые ресурсы, процессы, данные, интерфейсы и диалоги. Приводятся
практические примеры моделирования компонентов систем с использованием средств
автоматизации CASE.
Пособие предназначено для студентов, обучающихся по направлению
« Прикладная информатика» и специализирующихся в области информационных систем
управления, а также может быть рекомендовано специалистам, имеющим отношение к
рассматриваемой области.
Текстовое электронное издание
Минимальные системные требования:
процессор с частотой 1,3 ГГц (Intel, AMD); оперативная память 256 МБ,
свободное место на винчестере 335 МБ; Windows (XP; Vista; 7 и т.п.)
Программное обеспечение:
Acrobat Reader, Foxit Reader либо любой другой их аналог
Дальневосточный федеральный университет
690922, Приморский край, г. Владивосток, о. Русский, п. Аякс, 10.
Тел./факс: (423) 226-54-43
Е-mail: dvfutip@yandex.ru, prudkoglyad.sa@dvfu.ru
Изготовитель CD-ROM:
Дальневосточный федеральный университет,
690922, Приморский край, г. Владивосток, о. Русский, п. Аякс, 10.
Подписано к использованию 09.04.2021 г.
Объем 4,81 Мб.
Тираж 50 экз.
© Сухомлинов А.И., 2016
© Сухомлинов А.И., 2021, с изменениями
© Оформление. ФГАОУ ВО ДВФУ, 2021
Оглавление
Предисловие................................................................................................................. 5
Глава 1. АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ ............................... 7
1.1. Введение в архитектуру информационных систем ....................................... 7
1.2. Представления как человеческий фактор восприятия
информационных систем....................................................................................... 10
1.3. Инфраструктура архитектуры информационных систем ........................... 13
1.4. Расширенная инфраструктура архитектуры ................................................ 19
1.5. Правила инфраструктуры............................................................................... 31
Ключевые термины............................................................................................. 37
Контрольные вопросы ........................................................................................ 37
Глава 2. РАЗРАБОТКА ИНФОРМАЦИОННЫХ СИСТЕМ
И МЕТОДОЛОГИИ................................................................................................... 39
2.1. Разработка систем ........................................................................................... 39
2.1.1. Традиционная разработка ....................................................................... 41
2.1.2. Современная разработка ......................................................................... 41
2.1.3. Жизненный цикл разработки систем ..................................................... 43
2.1.4. Стандарты................................................................................................ 51
2.2. Методологии разработки систем ................................................................... 59
2.3. Эволюция методологий .................................................................................. 62
2.4. Метод структурного анализа и дизайна систем SSADM ............................ 80
2.5. Информационная инженерия IE .................................................................... 93
2.6. Методология MERISE .................................................................................. 111
Ключевые термины.............................................................................................. 123
Контрольные вопросы ......................................................................................... 124
Глава 3. АНАЛИЗ МЕТОДОЛОГИЙ .................................................................... 126
3.1. Определение методологий ........................................................................... 126
3.2. Обоснование необходимости методологий................................................ 129
3.3. Истоки методологий ..................................................................................... 134
3.4. Применение методологий ............................................................................ 141
3.5. Инфраструктура для сравнения методологий............................................ 146
3.6. Сравнение методологий ............................................................................... 158
Ключевые термины.............................................................................................. 172
Контрольные вопросы ......................................................................................... 172
Глава 4. ОСНОВНЫЕ ПРИНЦИПЫ РАЗРАБОТКИ
ИНФОРМАЦИОННЫХ СИСТЕМ ........................................................................ 174
4.1. Жизненный цикл и методологии разработки систем ............................... 175
4.2. Базовые принципы разработки систем ....................................................... 177
3
4.3. Практический пример предприятия ............................................................ 185
Ключевые термины.............................................................................................. 194
Контрольные вопросы ......................................................................................... 194
Глава 5. ПЛАНИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ................... 196
5.1. Идентификация и выбор проектов разработки систем ............................. 196
5.1.1. Процесс идентификации и выбора проектов разработки
информационных систем ................................................................................. 197
5.1.2. Выход и результаты............................................................................... 203
5.2. Корпоративное планирование и планирование информационной
системы.................................................................................................................. 205
5.2.1. Корпоративное стратегическое планирование .................................. 207
5.2.2. Планирование информационной системы............................................ 212
5.3. Практический пример: Планирование информационной системы ........ 225
5.3.1. Проблемные области текущего состояния предприятия ................. 226
5.3.2. Планирование предприятия ................................................................... 226
5.3.3. Планирование информационной системы............................................ 230
Ключевые термины.............................................................................................. 246
Контрольные вопросы ......................................................................................... 246
Глава 6. АНАЛИЗ СИСТЕМ .................................................................................. 248
6.1. Структурирование требований процессов системы .................................. 250
6.1.1. Моделирование процесса ........................................................................ 251
6.1.2. Составление диаграмм потока данных ............................................... 253
6.1.3. Использование DFD в процессе анализа............................................... 271
6.2. Структурирование требований данных системы....................................... 280
6.2.1. Процесс логического моделирования данных....................................... 282
6.2.2. Конструирование модели данных ......................................................... 289
Ключевые термины.............................................................................................. 305
Контрольные вопросы ......................................................................................... 305
Глава 7. ПРОЕКТИРОВАНИЕ СИСТЕМ ............................................................. 307
7.1. Проектирование базы данных...................................................................... 308
7.2. Проектирование интерфейсов и диалогов.................................................. 321
7.2.1. Проектирование интерфейсов.............................................................. 321
7.2.2. Проектирование диалога ....................................................................... 338
7.2.3. Проектирование интерфейсов и диалогов в графической среде...... 345
Ключевые термины.............................................................................................. 350
Контрольные вопросы ......................................................................................... 351
ЗАКЛЮЧЕНИЕ ....................................................................................................... 353
БИБЛИОГРАФИЧЕСКИЙ СПИСОК.................................................................... 358
Предисловие
Как отмечают современные исследователи в течение уже более
20 лет, всевозрастающая потребность современного общества в информационных системах остается в большой мере неудовлетворенной, несмотря на колоссальный объем инвестиций, произведенных в
информационные технологии в частном и государственном секторе.
На решение этой сложной и комплексной проблемы, преодоления
разрыва между потребностями менеджмента и возможностями существующих прикладных систем, направлены сегодня усилия многих
ученых и практиков. Хотя причины многих глобальных неудач и материальных потрясений, порожденных данной проблемой, уже давно
вскрыты и разъяснены, она продолжает существовать, и статистика
успешности разработок до сих пор не изменилась.
Целями настоящего учебного пособия являются:
1) систематическое представление области разработки автоматизированных информационных систем;
2) концентрация внимания на вопросах архитектуры, методологий,
принципов разработки, стратегического планирования, анализа и
проектирования информационных систем;
3) демонстрация возможностей комплексного применения изложенных положений теории, методологий, методов и средств CASE на
примере разработки информационной системы предприятия;
4) отражение все еще существующих до сих пор проблем, требующих теоретического решения, в рассматриваемой области.
Содержание учебного пособия построено в соответствии с требованиями федерального государственного образовательного стандарта
высшего образования по направлению подготовки «Информатика и
вычислительная техника», а также профессионального стандарта
«Системный аналитик» Минтруда РФ.
Пособие состоит из семи глав, включающих архитектуру информационных систем, разработку информационных систем, анализ методологий, принципы разработки и планирование информационных
систем, анализ и проектирование систем. В материал пособия входит
5
большое количество иллюстративного материала. В конце каждой
главы даются ключевые термины и вопросы для контроля.
Пособие предназначено для студентов бакалавриата и магистратуры, обучающихся по направлению «Информатика и вычислительная
техника» и специализирующихся в области профессиональной деятельности «Автоматизированные системы обработки информации и
управления», а также может быть рекомендовано специалистам,
имеющим отношение к рассматриваемой области.
Глава 1. АРХИТЕКТУРА
ИНФОРМАЦИОННЫХ СИСТЕМ
Увеличивающийся масштаб разработки и уровень сложности приложений информационных систем вынуждает применять некоторую
логическую конструкцию или архитектуру для определения и контроля интерфейсов и интеграции всех компонентов системы. Мы
встречаемся с трудностями, обсуждая друг с другом архитектуру информационных систем потому, что существует набор архитектурных
представлений вместо одной единственной архитектуры. Они аддитивные и дополняющие. Существуют веские причины расходования
ресурсов для разработки каждого архитектурного представления информационной системы. И существуют риски, связанные с не проведением разработки любого одного из этих архитектурных представлений. Эта глава рассказывает об архитектуре информационных систем путем создания описательной, нейтральной и объективной инфраструктуры и вырабатывает некоторые предварительные выводы о
ней. Она также распространяет подобный набор архитектурных представлений на другие области, связанные с производством сложной
технической продукции. Обсуждение ограничивается архитектурой и
не включает методологию стратегического планирования.
1.1. Введение в архитектуру информационных систем
Тема архитектуры информационных систем в настоящее время все
более актуальна. Тридцать лет назад эта тема не была так важна потому, что технология сама по себе не предусматривала ни ширины
охвата, ни глубины сложности в информационных системах. Ограничения, свойственные тогда доступным 4К машинам, например, ограничивали конструирование и приводили к субоптимальным подходам
для автоматизации бизнеса.
Современные технологии быстро устраняют концептуальные и
финансовые ограничения. Сегодня не трудно рассуждать об очень
больших и сложных применениях информационных систем, всецело
7
охватывающих предприятие. Можно быстро определить достоинства
больших сложных подходов информатизации, ориентированных на
предприятие. Такие системы обеспечивают гибкость в управлении
переменами в бизнесе и согласованность в управлении его ресурсами.
Не смотря на это более традиционные, простые, субоптимальные
подходы конструирования позволяют создавать системы, которые
относительно экономичны, быстро внедряемы и более легки в дизайне и управлении
В любом случае, поскольку технология допускает распределение
большого количества компьютерных средств некоторой комплектности в географически разнесенных отдельных местах, возникает острая потребность в некоторой структуре или архитектуре, потому что
децентрализация без структуры означает хаос. Следовательно, для
удержания бизнеса от дезинтеграции, концепция архитектуры информационных систем становится необходимостью для установления
некоторого порядка и контроля в инвестиции ресурсов информационных систем. Осуществляемые расходы и успех бизнеса, все более
зависящие от информационных систем, требуют более строгого подхода к управлению этими системами.
Рассмотренное предположение, что осмысление архитектуры информационных систем является важным для разработки строгого подхода, естественно вызывает вопрос: «Что на самом деле является архитектурой информационных систем?» К сожалению, среди сторонников
архитектуры информационных систем настолько мало согласованности
в концепциях или в спецификациях «архитектуры», что термин «архитектура информационных систем» теряет свой смысл. Более того, представляется, вероятно, необоснованным само ожидание такого согласия
или общности в определении от профессионального сообщества по обработке данных. Эмоциональная приверженность, связанная с устоявшимися интересами различных школ, требует нейтрального, беспристрастного, независимого источника в качестве необходимого условия
для любой приемлемой работы в этой области.
Так или иначе, вероятно существует необходимость в своего рода
инфраструктуре для совершенствования различных архитектурных
8
концепций и спецификаций, для обеспечения ясности осуществления
профессиональных связей, предоставляющих возможность улучшения и интеграции методологий разработки и средств, и для упрочения
доверия и уверенности в инвестиции системных ресурсов.
Несмотря на то, что архитектура информационных систем связана
с информационной стратегией и бизнес-стратегией, эта глава сознательно ограничена архитектурой и ее не следует истолковывать как
методологию стратегического планирования. Разработка бизнесстратегии и ее связь со стратегиями информационных систем, которые, разумеется, проявляют себя в архитектурной формулировке, является важным предметом для исследования, но этот вопрос является
вполне независимым от темы настоящей главы, которая определяет
инфраструктуру для архитектуры информационных систем.
Использование термина «архитектура» при рассмотрении сложностей современных информационных систем уже стало обычным делом. Специалисты по информационным технологиям употребляют
термины архитектура данных, архитектура приложений, архитектура
сетей, архитектура технологий и т.д. Архитектуру информационных
систем можно определить следующим образом.
Архитектура информационных систем дает комплексную инфраструктуру или рамки, в которых разные люди с различными точками
зрения могут организовать и рассматривать главные конструктивные
блоки информационных систем. По своему существу, архитектура
информационных систем обеспечивает основу для организации всех
компонент любой разрабатываемой информационной системы.
Рассматриваемые в данной главе инфраструктура архитектуры
информационных систем основана на идее Джона Захмана, сформулированной им в 1987 г. Она дает возможность создания интегрированной всесторонней спецификации взаимосогласованных компонентов системы, отражающей представления различных категорий людей, имеющих к ней отношение. Благодаря данным свойствам рассматриваемая концепция может быть применена в качестве основы
для создания новых подходов и методологий разработки информаци9
онных систем, обеспечивающих в результате создание приложений,
соответствующих истинным потребностям организации.
1.2. Представления как человеческий фактор
восприятия информационных систем
Процесс разработки информационных систем вовлекает в себя
различных людей. Различные категории людей рассматривают или
представляют информационную систему по-разному. Менеджеры,
пользователи и технические специалисты – представители каждой из
этих категорий рассматривают информационную систему различным
образом и на различных уровнях подробностей. Всех этих людей
совместно принято называть лицами, заинтересованными в системе.
Они могут быть явно классифицированы на группы: владельцы систем, пользователи систем, дизайнеры и изготовители систем.
Каждая из вышерассмотренных групп, рассматривая информационную систему, может концентрировать свое внимание на различных
ее аспектах. Например, один дизайнер может конструировать базу
данных, другой может разрабатывать интерфейсы пользователей, в то
время как третьему может быть поручено конструирование программ
и т. д. Можно выделить, как минимум, три аспекта рассмотрения информационной системы. Это – данные, процессы и география. Количество аспектов рассмотрения системы можно расширить, добавив
организацию и мотивацию людей, время, интерфейсы и т.п.
Владельцы, пользователи, дизайнеры и изготовители – представители всех этих категорий вместе должны присутствовать в составе
группы разработки информационной системы любого отдельно взятого проекта. Этих участников деятельности, связанной с информационными системами, объединяет то, что все они относятся к той категории работников, которую Министерство труда США называет
информационными работниками.
Владельцы системы. У любой системы – большой или малой –
имеются владельцы. Владельцы – это заказчики информационных систем и главные их сторонники. Они обычно отвечают за бюджетиро10
вание и время при разработке, использовании и сопровождении информационной системы. Они оплачивают создание и обслуживание
системы. Они владеют системой, устанавливают приоритеты для системы, определяют стратегию использования. Они также отвечают за
технико-экономическое обоснование системы и ее приемку.
Владельцы склонны рассматривать информационную систему с
точки зрения сферы ее применения (замысел и видение, цели и задачи, затраты и выгоды). Они склонны мыслить очень обобщенными
понятиями, а не подробностями. Их меньше всего впечатляют технологии, используемые в информационных системах. Они больше озабочены величиной средств, возвращенных системой. Эта величина
измеряется различными способами. Каково назначение системы? Каким является видение системы – цели и задачи? Во сколько обойдется
создание системы? Сколько будет стоить функционирование системы? Будут ли эти расходы компенсированы измеряемыми выгодами?
Каковы будут нематериальные выгоды?
Владельцы обычно происходят из рядов управленцев. Владельцами средних и больших информационных систем обычно являются
менеджеры среднего или высшего уровня. Владельцами меньших систем могут быть менеджеры среднего или более низкого уровня. Для
персональной информационной системы владелец и пользователь являются одним и тем же лицом.
Пользователи системы – это люди, которые фактически на регулярной основе используют систему для выполнения своей работы или
для поддержки ее выполнения и непосредственно получают от нее выгоду – выбирая, проверяя, вводя, реагируя, запоминая и обмениваясь
данными и информацией. Пользователи системы определяют проблемы, которые должны быть решены, возможности, которые должны
быть использованы, требования, которые должны быть выполнены,
бизнес-ограничения, которые должны быть установлены (или устанавливаться информационной системой). Они также склонны к заинтересованности в легкости изучения и использования системы.
В противоположность владельцам систем они склонны меньше
вникать в расходы и выгоды, получаемые от систем. Вместо этого
11
они больше концентрируются на бизнес-требованиях к системе. Несмотря на то, что со временем пользователи становятся все более образованными в технологиях, их основной интерес все же связан с выполнением возложенной на них работы. В современном деловом мире, ориентированном на коллективную работу, пользователи системы
часто работают бок о бок с дизайнерами системы.
Существует много классов пользователей. Среди них можно отметить следующие. Внутренние пользователи – это конторский и обслуживающий персонал, технический и служебный персонал, высококвалифицированные специалисты (knowledge workers), мастера,
менеджеры среднего и высшего уровня, удаленные и мобильные
пользователи. Современные информационные системы пересекают
привычные традиционные границы своих компаний и присоединяют
другие предприятия и лиц в качестве внешних пользователей системы. Кроме того, движимые глобальной конкуренцией, компании модернизируют свои информационные системы для прямой связи и взаимодействия со своими деловыми и торговыми партнерами, поставщиками, заказчиками и даже с конечным потребителем, расширяя,
таким образом, круг внешних пользователей системы. Это усложняет
разработку информационных систем, но приносит существенную выгоду. В современных условиях компания не конкурентоспособна, пока не будет готова использовать межсистемные интерфейсы.
Дизайнеры систем – технические специалисты, которые конструируют систему, отвечающую определенным требованиям. Они транслируют требования и ограничения бизнеса в технические решения.
Они конструируют компьютерные файлы, базы данных, ввод, вывод,
экранные формы, сети и программы, которые будут соответствовать
требованиям пользователей системы.
Дизайнеры систем находятся ближе к информационным технологиям, чем к владельцам и пользователям систем. Очень часто они
должны осуществлять выбор технологий и/или разрабатывать системы в рамках ограничений выбранных технологий. Сегодняшние дизайнеры систем склонны обращать внимание на технические профессии: дизайнеры баз данных (аспект данных), программисты (аспект
12
процессов или программ), специалисты по вычислениям на персональных компьютерах и системные интеграторы (аспект интерфейсов), специалисты по сетям и телекоммуникациям (аспект географии). Во многих случаях дизайнеры системы могут также являться ее
изготовителями.
Изготовители систем – это технические специалисты, которые
создают, тестируют и сдают систему в эксплуатацию. Они непосредственно создают компоненты системы на основе спецификаций разработанных дизайнерами. Во многих случаях дизайнер системы и изготовитель для одного компонента являются одним и тем же лицом.
Прикладной программист является классическим примером изготовителя информационной системы. Тем не менее, в процесс изготовления системы могут быть вовлечены и другие технические специалисты: системные программисты, программисты баз данных, сетевые администраторы, специалисты по программному обеспечению
микрокомпьютеров.
Системный аналитик, или специалист по системному анализу
должен обладать компетенцией решения вопросов для каждого из
представлений системы, свойственных рассмотренным категориям
заинтересованных лиц. Для владельцев и пользователей системы он,
как правило, создает и проверяет их представления. Для дизайнеров и
изготовителей системы он обеспечивает согласование и совместимость технических и бизнес-представлений.
1.3. Инфраструктура архитектуры информационных систем
Применительно к информационной системе слово «архитектура»
является метафорой, которая может применяться наравне как к конструкции компьютерной системы, так и к конструкции дома. Инфраструктура архитектуры информационной системы представляет собой развитие этой метафоры. Инфраструктура уподобает представления, используемые для описания информационной системы, представлениям, порождаемым архитектором при проектировании и строительстве дома.
13
Инфраструктура архитектуры информационной системы образована пятью представлениями: масштабом предметной области, или
намерением, моделью предприятия, моделью системы, технологической моделью или технической моделью и компонентами.
Намерение. Первый из создаваемых архитектурных набросков
информационной системы управления – это схемы, описывающие в
терминах высокого уровня размер, очертания, пространственные отношения и основную цель будущей структуры. Это описание соответствует пояснительной записке планировщика или инвестора, которые хотят оценить рамки возможностей будущей системы, то как она
могла бы действовать, и сколько это будет стоить. Документы, составляемые на этом уровне, как можно менее техничны, от них не
требуется полноты.
Модель предприятия, или модель бизнеса. Следующими являются
схемы разработчика, которые изображают будущую систему в форме
представления владельца системы (заказчика), который в дальнейшем
должен будет взаимодействовать с этой системой в ежедневном режиме
ведения повседневного бизнеса. Эти схемы соответствуют модели предприятия, которая фактически является дизайном бизнеса и показывает
объекты и процессы бизнеса, а также их взаимодействие.
Модель системы. Задача архитектора состоит в переводе или
отображении схем модели предприятия в подробные технические
условия или спецификации, соответствующие представлению информационной системы дизайнером. Эти спецификации и составляют
модель системы. Она конструируется системным аналитиком, который должен определить элементы данных и функций, представляющих объекты и процессы бизнеса.
Технологическая модель. Подрядчик должен переработать схемы
модели системы и отобразить их в схемы представления изготовителя, которое должно учитывать ограничения средств, технологий и
других составных частей. Схемы изготовителя соответствуют технологической модели, которая должна адаптировать (привязать) модель
информационной системы к возможностям языков программирования, устройств ввода-вывода и другим технологиям.
14
Компоненты. Субподрядчики работают с рабочими схемами и документами, которые определяют в подробностях части и элементы.
Они соответствуют подробным спецификациям, которые предназначены для программистов, которые создают отдельные модули, не касаясь полного контекста или структуры системы.
Рассмотренные пять представлений соответствуют пяти строкам инфраструктуры архитектуры информационной системы, изображенной на
рис. 1.1 и повторяющей первоначальную версию, предложенную Джоном Захманом в 1987 г. Три столбца описывают три аспекта информационных систем: данные, функции и сети для каждого из пяти уровней.
Таким образом, в целом данная модель инфраструктуры показывает, что
процесс создания информационной системы должен последовательно
иметь дело с каждым из пяти уровней представления. При этом переход
к решениям, связанным со следующим уровнем представления, считается возможным только после принятия согласованных решений по всем
трем аспектам информационной системы на предыдущем уровне. Каждая из пятнадцати образованных таким образом ячеек таблицы символизирует определенную область принятия решений для создаваемой информационной системы и обозначения, используемые для описания соответствующих представлений информационных систем.
Три столбца на рис. 1.1 представляют данные, функции и сеть информационной системы. Для каждой из пяти строк столбец А показывает объекты, включаемые в рассмотрение информационной системой,
столбец В показывает выполняемые функции, столбец С показывает
местоположение и взаимосвязи.
Для физических процессов в строительстве и технике столбец А
представляет материалы, столбец В – функции, столбец С – геометрию. Каждая строка характеризуется особой ролью, или представлением, особым набором ограничений и, следовательно, особыми моделирующими структурами. В табл. 1.1 показаны представления, ограничения и модели для трех столбцов рис. 1.1, которые были описаны
в первой работе Захмана.
15
ДАННЫЕ
Объект, Отношение
НАМЕРЕНИЕ
Список объектов, важных для бизнеса
ФУНКЦИЯ/ПРОЦЕСС
Функция/процесс, Аргумент (вход/выход)
Список процессов, выполняемых бизнесом
СЕТЬ
Узел, Связь
Список мест, где осуществляется бизнес
(ПРЕДСТАВЛЕНИЕ ПЛАНИРОВЩИКА)
МОДЕЛЬ
ПРЕДПРИЯТИЯ
(ПРЕДСТАВЛЕНИЕ ВЛАДЕЛЬЦА)
МОДЕЛЬ СИСТЕМЫ
ОБЪЕКТ – класс бизнесобъектов
Например, E-R схема
(объект/отношение)
ФУНКЦИЯ – класс
бизнеспроцессов
Например, диаграмма
потока функций
ФУНКЦИЯ – бизнесОБЪЕКТ – бизнес-объект
ОТНОШЕНИЕ – бизнес-
процесс
УЗЕЛ – подразделение
АРГУМЕНТ – бизнес-
бизнеса
правило
ресурсы
СВЯЗЬ – бизнес-
Например, схема потока
данных
отношение/поток
Например, архитектура
распределенной системы
Например, модель данных
(ПРЕДСТАВЛЕНИЕ КОНСТРУКТОРА)
ТЕХНОЛОГИЧЕСКАЯ МОДЕЛЬ
УЗЕЛ – процессор,
ОБЪЕКТ – объект данных
ОТНОШЕНИЕ – отношение
ПРОЦЕСС – функция
данных
Например, дизайн базы
данных для среды
СУБД
АРГУМЕНТ – данные потока
(ПРЕДСТАВЛЕНИЕ ИЗГОТОВИТЕЛЯ)
Например, описание
данных
(ПРЕДСТАВЛЕНИЕ СУБПОДРЯДЧИКА)
ОБЪЕКТ – поля
ОТНОШЕНИЕ – адреса
ФАКТИЧЕСКАЯ СИСТЕМА
при-
ложения
Например, граф структуры программы приложения
ПРОЦЕСС – компьютерная
ОБЪЕКТ – строка
ОТНОШЕНИЕ – ключ
КОМПОНЕНТЫ
УЗЕЛ – местоположение
бизнеса
Например, логистическая сеть
функция
форматы
экранного устройства
Например, программа
АРГУМЕНТ –
ПРОЦЕСС – команды языка
АРГУМЕНТ – управляющие
блоки
ДАННЫЕ
ФУНКЦИЯ
и.т.п.
СВЯЗЬ – характеристики
линии связи
Например, архитектура
системы
УЗЕЛ – аппаратное
средство/системная программа
СВЯЗЬ – спецификация линии связи
Например, архитектура
сети
УЗЕЛ – адреса
СВЯЗЬ – протоколы
СЕТЬ
Рис. 1.1. Первоначальная инфраструктура архитектуры
информационных систем
16
память
Таблица 1.1
Характеристики строки инфраструктуры
Строка
Представление
1
Планировщик
2
Владелец
3
Дизайнер
Ограничения
Финансовые/
внешние
Использование/
стратегия
Структура/операции
4
Изготовитель
Технология
5
Субподрядчик
Внедрение
Модель
Намерение
Модель
предприятия
Модель системы
Технологическая
модель
Внеконтекстные
модели
Ограничения обладают свойством аддитивности. Это означает, что
при создании новой модели на некотором уровне представления к
ограничениям текущей строки добавляются ограничения строк вышележащих уровней. В идеальном случае модель нового уровня не
должна быть несхожей настолько, что из нее не может быть выведена
(или реверсивно сконструирована) модель более высокого уровня
представления. Это приводит к проблеме управления качеством: для
обеспечения гарантии того, что такие преобразования модели (через
последующее применение дополнительных ограничений) не приведут
к такому сокрытию начальных целей бизнеса, что в конечном продукте начальные бизнес-требования станут нераспознаваемыми.
На практике ограничения на более низком уровне могут стать
несовместимыми с моделью прилегающего верхнего уровня. Следовательно, разработчик, ответственный за эти два уровня, должен инициировать диалог для определения того, что должно быть изменено, и
обеспечить отсутствие расхождений в ожидаемых результатах между
этими двумя представлениями. Не важно, насколько желательным или
эстетически привлекательным могло бы быть данное конкретное средство; но если оно нарушает закон или физику, оно не может быть применено. Следовательно, разработчик должен уведомить владельца и
подробно, не двусмысленно согласовать альтернативу.
17
Столбцы инфраструктуры архитектуры информационной системы
представляют различные абстракции или различные методы описания
реального мира. Причина для изоляции одной переменной (абстракции) и в то же самое время подавления всех других состоит в необходимости ограничения (снижения) сложности проблемы разработки.
Например, существует значительная сложность конструировать отношения предприятия «процесс-процесс», не обращая одновременно
внимания на конструкторские задачи, касающиеся отношений «объект-объект» и «местоположение-местоположение». Однако, поскольку процессы, объекты и местоположение – все они абстракции одного
и того же предприятия, каждая из них имеет отношение ко всем
остальным. Следовательно, во время конструирования любой из них,
структурная целостность других, несомненно, может оказаться под
нежелательным воздействием. Проблема здесь состоит в том, что при
конструировании каждой абстракции, осознавая оказываемое при
этом влияние на все остальные, необходимо остерегаться не желаемой стороны эффектов, появляющихся намного позже, после того,
когда их можно было бы избежать. Свидетельство этой свободы (или
вытекающего из этого недостатка) наблюдается в большинстве современных портфелей приложений. В течение пятидесяти лет мы
бессознательно оптимизировали функции за счет данных и только
сейчас мы начинаем обнаруживать негативную сторону эффекта.
Несмотря на то, что первоначальная инфраструктура предлагала
ограничения моделирования для каждой из 15 ячеек, она не включала
языка формальной спецификации, пригодного для детального дизайна системы или для заполнения репозитория в цикле разработки приложений (Application Development Cycle, AD/Cycle) или в других
средствах автоматизированного конструирования программ (Computer-Aided Software Engineering, CASE). Единственным средством для
формальной спецификации, явно указанным в описании инфраструктуры, является язык E-R диаграмм.
Когда инфраструктура была определена впервые, было довольно
легко найти примеры существующих средств описания для всех ячеек
столбцов данных и процессов. Была даже выполнена творческая ра18
бота для столбца сетей, в то время как распределенная обработка еще
только впервые распространялась. Однако эта работа не была широко
принята сообществом профессионалов по обработке данных. Последующее наступление технологии рабочих станций, концепций клиент-сервер и распределенных систем снова концентрирует внимание
на сетевых положениях, и вероятно, что этот формализм начнет применяться и распространяться по мере того, как удаленная обработка и
хранение станут реальностью. В любом случае примеры многих ячеек
первоначальной трехколоночной инфраструктуры использовались
практиками и теоретиками, подтверждая опытным путем релевантность ячеек инфраструктуры в том виде, как они были первоначально
описаны.
1.4. Расширенная инфраструктура архитектуры
Три колонки рис. 1.1 соответствуют трем вопросительным словам:
«что», «как» и «где». Для каждой из пяти строк столбец А показывает
объекты реального мира, вовлеченные в рассмотрение информационной системой, столбец В показывает как они обрабатываются, столбец С показывает где они размещены. С тех пор как инфраструктура
архитектуры информационной системы была впервые опубликована
в 1987 г., она была расширена рассмотрением трех других вопросительных слов: «кто», «когда» и «почему». Каждое из этих слов обращает внимание на отдельный аспект информационной системы: кто
работает с системой, когда имеют место события, и почему происходят события. Все шесть поставленных вопросов для каждой из пяти
строк приводят к 30 различным представлениям информационной системы.
В традиционном сообществе по обработке данных существует немного формализмов для ячеек кто, когда и почему. Некоторые из таких формализмов существуют в других областях или даже в некоторых узких (но менее широко понимаемых) областях по обработке
данных, например, формализмы, предложенные еще в конце
1970-х гг. – начале 1980-х гг. в области концептуального моделиро19
вания данных и временной размерности данных. Но их общая недоработанность для применения в рамках рассматриваемой инфраструктуры является причиной того, что описания новых ячеек могут
сегодня иметь скорее более теоретический и менее эмпирический характер. Следовательно, при выдвижении гипотез о содержании ячеек
этих дополнительных трех столбцов необходимо осмыслить правила
инфраструктуры и строго их придерживаться.
Отсутствие общепринятых формализмов для этих столбцов также
означает, что принятая терминология не основывается на давно установившихся традициях. Как во всяком современном достижении в
инфраструктуре архитектуры в будущем могут происходить новые
проникновения, а используемая в ней терминология может стать более точной и стандартизованной. До тех пор пока это не произойдет
названия содержания ячеек, используемые в этой главе, должны рассматриваться как рекомендуемые.
Столбец люди (кто). Абстрактное рассмотрение концепции «люди» вне реального предприятия является необходимым из-за важности конструирования организационной инфраструктуры или отношений предприятия «люди-люди». Одна из трудностей проектирования
организации связана с распределением работ и структурой полномочий и ответственности. Следовательно, базовой моделью столбца является модель «люди-работа-люди», а классическая схема организационной структуры может рассматриваться как графическое изображение этой базовой модели (рис. 1.2).
Вертикальное измерение схемы представляет передачу полномочий, а горизонтальное измерение – распределение ответственности.
Классическая организационная схема обычно не пытается показать
определение результата деятельности полномочий или результата
функциональной деятельности (ответственности). Эти определения
работы, если они только определены, представляются в тексте как
дополнительные документы. Однако допуская, что если организационная структура и дизайн деятельности были бы восприняты предприятием достаточно важными, чтобы приписать к ним некоторую
техническую дисциплину, то можно предположить, что для поддерж20
Полномочия
ки фактического дизайна организации мог бы разработан графический формализм, подобный показанному на рис. 1.2.
Отношение
иерархического
контроля
Отношение
координации
действий
Операционные
отношения
Ответственость
Рис. 1.2. Пример организационной схемы
Что касается самой схемы на рис. 1.2, сторонники динамической
организации определяют два стиля распределения работ: рынки и
иерархии. Вкратце, предприятие будет формировать структуру свободного рынка, если природа транзакций между подразделениями организации будет простой, хорошо определенной и повсеместно понятной. В этом случае организация при распределении работ просмотрит всех возможных работников и определит того, кто для нее
более подходит по условиям цены и качества.
В противоположность этому, когда внутриорганизационная транзакция является сложной, не очень четко определенной и не является
повсеместно понятной, предприятие установит иерархию, то есть регулятивную организацию, которая будет произвольно определять ре21
зультат работы, график и расходы, которые связывают подчиненные
организации. Этот метод во многом похож на нефтяную компанию,
которая произвольно определяет номенклатуру очищенного продукта, графики и трансфертное ценообразование продукта (назначение
цен на товары или услуги, предоставляемые одним самостоятельным
подразделением компании другому самостоятельному подразделению) на пути его перемещения от очистки к оптовой организации или
к организации розничного распределения.
Не существует требования для объекта, который распределяет работу, или которому распределяется работа, он может быть либо организацией, либо отдельным лицом. Он также может быть машиной
или программой-агентом, как в системах искусственного интеллекта.
Следовательно, вместо определения для столбца «люди» абстрактного объекта, такого как организация, лицо или пользователь, представляется более подходящим выбрать объект с более общим именем, таким как «агент», который можно применять как к человеку, так и к не
человеку.
Соединительное звено «работа», возможно, должно интерпретироваться как результат работы, чтобы избежать путаницы с концепцией
процесса или функции, которая рассматривается в столбце «процесс».
В дальнейшем оно могло бы обозначать своего рода представление
материалов пользователем или вход/выход процесса. Чтобы избежать
какой-либо путаницы между концепциями результата работы столбца
«люди» и входом/выходом столбца «процесс» было бы полезным изменить первоначальное название соединительного звена в столбце
«процесс» с «вход/выход» на «аргумент», который является математическим термином для входа функции, являющейся средством преобразования, как, например, в выражении f(x) = K, где f является преобразованием, x – входным аргументом и К – выходом.
В табл. 1.2 показан вид информации, которая должна находиться в
каждой строке столбца «люди». Смысл объектов в столбце изменяется с изменением представления от строки к строке, и этот смысл совместим с ячейками других столбцов в той же самой строке. Это озна22
чает, что смысл ячеек должен быть совместим с глобальной инфраструктурой вертикально и горизонтально.
Таблица 1.2
Содержание ячеек в столбце люди (кто)
Строка
1
2
Представление
Пример ячейки Агент
Работа
Планировщик
Список
организаций/
подразделений
Класс агента
Владелец
Организационная структура
Подразделение
организации
Результат деятельности
Роль
Единица
работы
Пользователь
Задание
Лицо
Транзакция
3
Дизайнер
4
Изготовитель
5
Субподрядчик
Архитектура
интерфейса
персонала
Человекомашинный
интерфейс
Архитектура
безопасности
Столбец время (когда). Эта абстракция реального мира предназначена для конструирования отношений типа «событие-событие»
для того чтобы установить критерий производительности и количественные уровни для ресурсов предприятий. Например, между «событием 1», заключающимся в анонсировании продукта в момент
времени t0, и «событием 2», состоящим в отправке продукта первому
клиенту в момент времени t1, находится промежуток времени (цикл,
период времени) (t1 - t0). Длина этого промежутка устанавливает
внешние обязательства предприятия также как и уровень ресурсов,
требуемых для выполнения этих обязательств. Вообще, чем короче
время цикла, тем больше требуется ресурсов для выполнения обязательств, и наоборот – чем оно длиннее, тем меньше необходимо требуемых ресурсов для этой цели.
23
Управление
На рис. 1.3 представлен пример графического представления, которое демонстрирует характеристики времени предприятия. Здесь
вертикальная ось соответствует управлению, а горизонтальная ось
представляет время. Точки или моменты времени изображены
окружностями, а продолжительность обозначена в виде цикла периодического процесса. В табл. 1.3 приводится список видов информации, которые соответствуют ячейкам столбца «когда».
E1
E2
E1.1
E1.3
E1.2
А1
1
2
3
4
5
6
7
8
9
10
14 15
11 12 13
Продолжительность
Рис. 1.3. Пример графика модели времени
Компоненты колоночной модели представляют собой точки времени (события) и длины времени (продолжительность). Задача предприятия состоит в создании графика событий и состояний, которые
максимизируют использование доступных ресурсов и в то же самое
время соответствуют требованиям внешних обязательств. Модели
ячеек столбца времени должны также поддерживать вертикальную и
горизонтальную совместимость в соответствии с правилами инфраструктуры.
24
Таблица 1.3
Содержание ячеек в столбце время (когда)
Строка Представление
1
Планировщик
2
Владелец
3
Дизайнер
4
Изготовитель
5
Субподрядчик
Пример ячейки
Событие
Основное
Список событий
событие
Бизнес
Основной график
событие
Структура
Системное
обработки
событие
Архитектура
Выполнить
управления
Временное
Прервать
определение
Цикл
Основной
цикл
Бизнес-цикл
Цикл
обработки
Цикл
компонента
Машинный
цикл
Столбец мотивации (почему). Столбец «почему» мог бы содержать наглядные представления, которые описывают мотивацию действий предприятия. Базовая колоночная модель этого столбца могла
бы, вероятно, представлять отношение «цели-средства-цели» или
«задачи-стратегии/методы-задачи». На рис. 1.4 показана гипотетическая модель на примере магазина видеозаписей. Эта упрощенная модель иллюстрирует основные положения. Более подробное представления деревьев типа «цель-подцель» используются в программах ведения деловых игр и программах планирования, решаемых методами
искусственного интеллекта.
Содержание ячеек в столбце мотивации, как это следует из правил
инфраструктуры, соответствует мотивации «цели-средства-цели»,
рассматриваемой в табл. 1.4.
Полная расширенная шестиколоночная инфраструктура архитектуры информационных систем показана на рис. 1.5. Здесь кратко
представлены виды описаний (моделей), соответствующие каждой из
тридцати ячеек. В табл. 1.5 приведен гипотетический пример, демонстрирующий описания некоторых данных, функций, сетей, организации, графиков и стратегий компании, осуществляющей регистрацию
автомобилей. Эти описания были составлены на основе спецификаций системы регистрации автомобилей.
25
Цель 1
50% оборот активов
в день
Цель 2
95% удовлетворение
спроса
Совпадение
Стратегия 1.1
Иметь запас
только высоковостреьованных
фильмов
Стратегия 1.2
Игнорировать
маловостребованные фильмы
Стратегия 1.3
Замена
имеющимися
отсутствующих
на складе
Стратегия 2.1
Иметь запас всех
известных
фильмов
Стратегия 2.2
Замена
имеющимися
отсутствующих
на складе
Конфликт
Цель 1.1.1
> 1 оборота
фильма в 2 дня
Стратегия:
Заказать
новую копию
Цель 1.2.1
< 1 оборота
фильма в 2 дня
Стратегия:
Получать
копии из хра_
нилища №2
Стратегия:
Продавать
имеющиеся
копии
Цель 1.3.1
1 замена на 2
отсутствующих
Стратегия:
Найти замену
по звезде или
предмету
Цель 2.1.1
Иметь в наличии
1 копию каждого
фильма
Стратегия:
Снизить цену
Стратегия:
Продавать
другим
магазинам
Совпадение
Рис. 1.4. Пример модели «цели-средства-цели
Стратегия 2.3
Получать копии
из хранилища
№2
Таблица 1.4
Содержание ячеек в столбце мотивация
Строка
Представление
Пример ячейки
1
Планировщик
Список целей
2
Владелец
Бизнес-план
3
Дизайнер
4
Изготовитель
5
Субподрядчик
Архитектура
знаний
Дизайн знаний
Определение
знаний
Цель
Основная
цель
Условие
Средство
Основные
стратегии
Бизнесстратегия
Альтернатива
Действие
Подусловие
Шаг
Бизнес-цели
Критерий
Естественный язык является универсальным средством для описания всего, что может быть описано. Но естественные языки обладают
свойством неоднозначности. Эта неоднозначность, с одной стороны,
полезна, а с другой, создает препятствие.
На ранних этапах разработки она позволяет задерживать принятие
решений, пока не будет выполнен последующий анализ. Но на более
поздних этапах они препятствуют автоматическому получению результата путем компиляции в исполняемые коды.
В табл. 1.5 показано применение естественного русского языка на
ранних этапах разработки. E-R схемы являются более формальным
средством обозначения, которое может представлять некоторую информацию, представленную на естественном языке, но не всю.
Символическая логика в обозначениях исчисления предикатов или
концептуальных графов является формальной и универсальной и может описать все, что может быть описано, и может быть транслирована в исполняемые коды. Таким образом, дальнейшее развитие формальных средств моделирования в контексте рассматриваемых положений инфраструктуры архитектуры информационных систем является одним из важных направлений будущих исследований.
27
ɇȺɆȿɊȿɇɂȿ
ȾȺɇɇɕȿ
ɎɍɇɄɐɂə/ɉɊɈɐȿɋɋ
ɋȿɌɖ
Ɉɛɴɟɤɬ, Ɉɬɧɨɲɟɧɢɟ
ɋɩɢɫɨɤ ɨɛɴɟɤɬɨɜ, ɜɚɠɧɵɯ ɞɥɹ ɛɢɡɧɟɫɚ
Ɏɭɧɤɰɢɹ, Ⱥɪɝɭɦɟɧɬ
ɋɩɢɫɨɤ ɩɪɨɰɟɫɫɨɜ, ɜɵɩɨɥɧɹɟɦɵɯ ɛɢɡɧɟɫɨɦ
ɍɡɟɥ, ɋɜɹɡɶ
ɋɩɢɫɨɤ ɦɟɫɬ, ɝɞɟ ɨɫɭɳɟɫɬɜɥɹɟɬɫɹ ɛɢɡɧɟɫ
ɉɅȺɇɂɊɈȼɓɂɄ
ɈȻɔȿɄɌ – ɤɥɚɫɫ
ɛɢɡɧɟɫ-
ɨɛɴɟɤɬɨɜ
ɆɈȾȿɅɖ
ɉɊȿȾɉɊɂəɌɂə
ɇɚɩɪɢɦɟɪ, E-R ɫɯɟɦɚ
ɎɍɇɄɐɂə – ɤɥɚɫɫ
ɛɢɡɧɟɫ-
ɩɪɨɰɟɫɫɨɜ
ɇɚɩɪɢɦɟɪ, ɞɢɚɝɪɚɦɦɚ
ɩɨɬɨɤɚ ɮɭɧɤɰɢɣ
ɍɁȿɅ – ɨɫɧɨɜɧɵɟ ɦɟɫɬɚ
ɪɚɫɩɨɥɨɠɟɧɢɹ ɛɢɡɧɟɫɚ
ɇɚɩɪɢɦɟɪ, ɥɨɝɢɫɬɢɱɟɫɤɚɹ ɫɟɬɶ
ȼɅȺȾȿɅȿɐ
ɈȻɔȿɄɌ – ɛɢɡɧɟɫ-ɨɛɴɟɤɬ
ɈɌɇɈɒȿɇɂȿ – ɛɢɡɧɟɫɆɈȾȿɅɖ ɋɂɋɌȿɆɕ
ɨɝɪɚɧɢɱɟɧɢɟ
ɇɚɩɪɢɦɟɪ, ɦɨɞɟɥɶ ɞɚɧɧɵɯ
ɎɍɇɄɐɂə – ɛɢɡɧɟɫ-ɩɪɨɰɟɫɫ
ȺɊȽɍɆȿɇɌ – ɛɢɡɧɟɫ-
ɪɟɫɭɪɫɵ
ɍɁȿɅ – ɪɚɡɦɟɳɟɧɢɟ ɛɢɡɧɟɫɚ
ɋȼəɁɖ – ɛɢɡɧɟɫ-ɫɜɹɡɶ
ɇɚɩɪɢɦɟɪ, ɫɯɟɦɚ ɩɨɬɨɤɚ
ɞɚɧɧɵɯ
ɇɚɩɪɢɦɟɪ, ɚɪɯɢɬɟɤɬɭɪɚ
ɪɚɫɩɪɟɞɟɥɟɧɧɨɣ ɫɢɫɬɟɦɵ
ɄɈɇɋɌɊɍɄɌɈɊ
ɎɍɇɄɐɂə – ɮɭɧɤɰɢɹ
ɈȻɔȿɄɌ – ɨɛɴɟɤɬ ɞɚɧɧɵɯ
ɈɌɇɈɒȿɇɂȿ – ɨɬɧɨɲɟɧɢɟ
ɌȿɏɇɈɅɈȽɂɑȿɋɄȺə ɆɈȾȿɅɖ
ɞɚɧɧɵɯ
ɇɚɩɪɢɦɟɪ, ɞɢɡɚɣɧ ɞɚɧɧɵɯ
ɩɪɢ-
ɥɨɠɟɧɢɹ
ȺɊȽɍɆȿɇɌ – ɩɪɟɞɫɬɚɜɥɟɧɢɟ
ɩɨɥɶɡɨɜɚɬɟɥɹ
ɇɚɩɪɢɦɟɪ, ɝɪɚɮ ɫɬɪɭɤɬɭɪɵ
ɍɁȿɅ – ɩɪɨɰɟɫɫɨɪ, ɩɚɦɹɬɶ
ɋȼəɁɖ – ɯɚɪɚɤɬɟɪɢɫɬɢɤɢ
ɥɢɧɢɢ ɫɜɹɡɢ
ɇɚɩɪɢɦɟɪ, ɚɪɯɢɬɟɤɬɭɪɚ
ɫɢɫɬɟɦɵ
ɂɁȽɈɌɈȼɂɌȿɅɖ
ɎɍɇɄɐɂə
ɈȻɔȿɄɌ – ɫɬɪɨɤɚ
ɈɌɇɈɒȿɇɂȿ – ɤɥɸɱ
ɄɈɆɉɈɇȿɇɌɕ
ɇɚɩɪɢɦɟɪ, ɨɩɢɫɚɧɢɟ
ɨɩɪɟɞɟɥɟɧɢɹ ɞɚɧɧɵɯ
ɋɍȻɉɈȾɊəȾɑɂɄ
ɈȻɔȿɄɌ – ɩɨɥɟ
ɈɌɇɈɒȿɇɂȿ – ɚɞɪɟɫ
ɎɍɇɄɐɂɈɇɂɊɍɘɓȺə ɋɂɋɌȿɆȺ
– ɤɨɦɩɶɸɬɟɪɧɚɹ
ɮɭɧɤɰɢɹ
– ɮɨɪɦɚɬ ɷɤɪɚɧɚ/ɭɫɬɪɨɣɫɬɜɚ
ɇɚɩɪɢɦɟɪ, ɩɪɨɝɪɚɦɦɚ
ȺɊȽɍɆȿɇɌ
ɎɍɇɄɐɂə – ɤɨɦɚɧɞɚ ɹɡɵɤɚ
ȺɊȽɍɆȿɇɌ – ɭɩɪɚɜɥɹɸɳɢɣ
ɛɥɨɤ
ȾȺɇɇɕȿ
ɍɁȿɅ – ɚɩɩɚɪɚɬɧɵɟ
ɫɪɟɞɫɬɜɚ/ɫɢɫɬɟɦɧɚɹ ɩɪɨɝɪɚɦɦɚ
ɋȼəɁɖ – ɫɩɟɰɢɮɢɤɚɰɢɹ ɥɢɧɢɢ ɫɜɹɡɢ
ɇɚɩɪɢɦɟɪ, ɚɪɯɢɬɟɤɬɭɪɚ
ɫɟɬɢ
ɍɁȿɅ – ɚɞɪɟɫ
ɋȼəɁɖ – ɩɪɨɬɨɤɨɥ
ɎɍɇɄɐɂə
Ɋɢɫ. 1.5. ɒɟɫɬɢɤɨɥɨɧɨɱɧɚɹ ɢɧɮɪɚɫɬɪɭɤɬɭɪɚ
ɚɪɯɢɬɟɤɬɭɪɵ ɢɧɮɨɪɦɚɰɢɨɧɧɵɯ ɫɢɫɬɟɦ
28
ɋȿɌɖ
ЛЮДИ
ВРЕМЯ
МОТИВАЦИЯ
Агент, Работа
Список организаций/агентов, важных
для бизнеса
Время, Цикл
Список событий, важных для бизнеса
Цель, Средство
Список бизнес целей/стратегия
АГЕНТ – основное
подраз-
деление
Например, организационная диаграмма
НАМЕРЕНИЕ
ПЛАНИРОВЩИК
ВРЕМЯ –
основное бизес-
событие
Например, основной
производственный график
ЦЕЛЬ/СРЕДСТВО – основная
цель/критический фактор
успеха
Например, бизнес-план
МОДЕЛЬ
ПРЕДПРИЯТИЯ
ВЛАДЕЛЕЦ
АГЕНТ – подразделение
организации
РАБОТА – предмет работы
Например, архитектура
интерфейса персонала
ВРЕМЯ – бизнес-событие
ЦИКЛ – бизнес-цикл
Например, структура
обработки
ЦЕЛЬ – бизнес-задача
СРЕДСТВО – бизнес-
стратегия
Например, архитектура
знаний
МОДЕЛЬ СИСТЕМЫ
КОНСТРУКТОР
ВРЕМЯ – системное
собы-
тие
АГЕНТ – роль
РАБОТА – результат
ЦИКЛ – цикл обработки
Например, человекомашинный интерфейс
Например, структура
контроля
ЦЕЛЬ – критерий
СРЕДСТВО – альтернатива
Например, дизайн знаний
ТЕХНОЛОГИЧЕСКАЯ МОДЕЛЬ
ИЗГОТОВИТЕЛЬ
АГЕНТ – пользователь
РАБОТА – задание
ВРЕМЯ – выполнить
ЦИКЛ – цикл компоненты
Например, архитектура
безопасности
Например, определение
времени
ЦЕЛЬ – условие
СРЕДСТВО – действие
Например, определение
знаний
КОМПОНЕНТЫ
СУБПОДРЯДЧИК
АГЕНТ – лицо
РАБОТА - транзакция
ОРГАНИЗАЦИЯ
ВРЕМЯ – прервать
ЦИКЛ – машинный
цикл
ГРАФИК
ЦЕЛЬ – часть условия
СРЕДСТВО – шаг
СТРАТЕГИЯ
Рис. 1.5. Окончание (начало см. на с. 2)
29
ФУНКЦИОНИРУЮЩАЯ СИСТЕМА
Таблица 1.5
Пример архитектуры компании в шестиколоночной инфраструктуре
что?объект/
отношение
как?функция/
аргумент
где?узел/
связь
кто?агент/
работа
компания, авто- регистрировать
директор, менеэмералд,
мобили, плата, , передавать,
джер, клерк, собнамерение
канзвс, голивуд,
планировщик лицезии, истории получать, обяственники автофлинт
автомобилей
зывать
мобилей
каждый автомомодель пред- биль представляприятия
ет конкретную
владелец
модель
собственность
передается регистрацией передачи
регистрации
фиксируются в
офисах компании
каждый офис
функциональная история автодолжен иметь
модель сизависимость мо- мобиля обновсвязь со штабстемы
дели от автомо- ляется модулем
дизайнер
квартирой комбиля
передачи
пании
отношение автопередача вы- записи отделетехнологиче- мобиль содержит
полняется cobol ний фирмы
ская модель столбец для
программой
дублируются в
изготовитель идентификатора
xfr397a
штаб-квартире
модели
клерк должен зафиксировать
каждую регистрацию
клерк должен
ввести информацию с терминала
когда?время/
цикл
почему?цели/
средства
регулировать
время продажи,
продажи, занирегистрации пемать деньги,
редачи, ликвидаразыскивать авции
томобили
когда автомобиль
вести точный
был выпущен,
учет и взымать
передан, уничтоплату
жен
обновления базы старая система
данных происхо- пакетной обрадят через нерав- ботки работает
номерные интер- недостаточно
валы
быстро
клерк заполняет
каждый модуль
бланк reg972,
вызывается вычтобы начать ребором из меню
гистрацию
установить ограselect sno from install tcp/ip link ничители для
компоненты
modelid pic x(15)
субподрядчик
hist where...
to oznet
направления очереди к клерку
работающая
данные
функция
сеть
организация
система
эффективное,
надежное обслуживание в пределах бюджета
использовать
удовлетворять
всплывающее окспецификациям
но, выбранное
каждого модуля
мышью
график
стратегия
1.5. Правила инфраструктуры
В предыдущих двух параграфах были рассмотрены примеры инфраструктуры информационных систем и содержание каждой ячейки.
Данный параграф описывает правила инфраструктуры более абстрактно. При его изучении для более ясного понимания этих правил
представляется полезным повторно обращаться к материалам рассмотренных примеров.
Правило 1. Столбцы таблицы инфраструктуры не упорядочены. Упорядоченность подразумевает приоритетность. Традиционные
программисты в своих суждениях и действиях склонны смещаться в
сторону функций. Они обычно предпочитают вначале рассматривать
функциональный столбец инфраструктуры. Они начинают с конструирования алгоритмов, которые реализуют функцию, и опускают
мысль о данных, как не заслуживающую внимания. Фактически они
могут даже заявить, что не существует необходимости в затрате ресурсов на определение других моделей, рассматриваемых инфраструктурой, что означает, что функциональная модель или модель
процессов является сама по себе достаточной. В результате применения такого их подхода все другие аспекты были бы ненамеренно игнорированы.
Точно таким же образом, программисты из области обработки и
управления данными считают, что столбец данных должен располагаться первым в инфраструктуре, потому что исторически доказано,
что если данные не будут сконструированы первыми, они постоянно
будут подвергаться компромиссным решениям (субоптимизации). По
смыслу, процесс и сеть могли бы быть также субоптимизированы в
интересах сохранения целостности структуры данных. Существуют
также такие лица, которые могли бы заявить, что столбец сети должен следовать первым, потому что местоположение данных и процессов определяет дизайн. Такой подход также приводит к субоптимизации других аспектов информационной системы. В равной степени представители других областей могли бы также «правдоподобно»
31
привести доводы, что столбцы «люди», «время» или «мотивация»
должны быть первыми.
В любом случае не существует естественного порядка для столбцов. Упорядоченность или последовательность подразумевают метод,
который реализует субъективную оценку. Все столбцы являются равно важными для всех абстракций одного и того же предприятия. Тот
и иной столбец может быть субоптимизирован в любой данный момент времени, но в этом случае представляется важным понимать,
почему было сделано такое компромиссное решение.
Правило 2. Каждый столбец имеет простую базовую модель.
Каждый столбец для удобства конструирования представляет абстракцию реального предприятия. Эти абстракции соответствуют
классификационной схеме, предложенной при помощи вопросительных слов «что», «как», «где», «кто», «когда» и «почему». Ответами на
эти вопросы являются базовые объекты или переменные колонок
«объекты», «функции», «места расположения», «люди», «время» и
«мотивации». В дополнение к этим базовым объектам очень важным
для дизайна являются соединительные звенья между ними. Столбец
данных, например, имеет простую базовую модель «объектотношение-объект». Колоночная переменная – это «объект», а соединительное звено – это «отношение».
Базовая модель для каждого столбца фактически является базовой
метамоделью. Она является базовой потому, что она одинаково применима для каждой ячейки в столбце. Она также «мета» потому, что
является моделью модели предприятия. Например, модель предприятия в ячейке А2 могла бы представлять ряд работников, имеющих отношение к организации, имеющей отношение к заказчикам, имеющих
отношение к продукции. Метамодель этой модели – это абстракция
«объект-отношение-объект». Подобным образом каждый столбец
имеет простую базовую модель, которая составляет общую метамодель для этого столбца. В табл. 1.6 представлены примеры для столбцов А, В и С.
32
Таблица 1.6
Компоненты для базовых метамоделей столбцов А, В, и С
Элементы
метамодели
Базовый объект
Соединяющее звено
Столбец А
Данные (что)
Объект
Отношение
Столбец В
Функции (как)
Функция
Аргумент
Столбец С
Сеть (где)
Узел
Связь
Правило 3. Базовая модель для каждого столбца должна быть
уникальной. Свойство уникальности является существенным для
каждой классификационной схемы. Следовательно, ни один объект и
ни одно соединительное звено в базовой колоночной модели не повторяется ни в имени, ни в понятии. Например, объект и отношение
являются уникальными в столбце А. Функция и аргумент уникальны
в столбце В. Объект не является эквивалентным функции, а отношение не эквивалентно аргументу. Они могут быть связаны друг с другом, т. к. они все являются абстракциями одного и того же реального
предприятия. Эта логика применима ко всем базовым колоночным
моделям, что подтверждает уникальность базовых моделей.
Правило 4. Каждая строка символизирует особое, уникальное
представление. Это правило наиболее легко демонстрируется в
строках 2, 3 и 4, которые изображают представления владельца, дизайнера и изготовителя. Каждое представление является особым в
том, что оно имеет отношение к собственному набору ограничений,
свойственному только ему. Например,
x Владелец: имеет дело с эксплуатационными ограничениями,
обоими эстетическими и практичности в концептуальном представлении конечного продукта.
x Дизайнер: имеет дело с ограничениями дизайна – законами физики или природы в логическом представлении конечного продукта.
x Изготовитель: имеет дело с ограничениями конструкции – современным состоянием методов и технологий в физическом представлении конечного продукта.
Каждое представление отражает особый набор ограничений, поэтому смысл (или определение) базового объекта в данном столбце
изменяется от строки к строке. Например, объект имеет один смысл
33
для владельца, другой для дизайнера и еще один для изготовителя. В
табл. 1.7 показаны примеры этих различий для столбца А.
Таблица 1.7
Изменения смысла объектов от строки к строке в столбце А
Строка Представление
Базовый объект
2
Владелец
Бизнес-объект (вещь реального мира)
3
Дизайнер
Объект данных (логическое представление)
Технический объект
4
Изготовитель
(физическое представление)
Смысл базового объекта столбца данных отличается от строки к
строке, поэтому и семантическое содержание ячеек в столбце является различным, что в, свою очередь, означает, что структура моделей
ячеек столбца, вероятно, должна быть отличной. Отметим, как изменяется смысл для всех строк и всех столбцов на рис. 1.5.
Правило 5. Каждая ячейка является уникальной. Каждому
столбцу соответствует уникальная базовая модель, которая определяет уникальность этого столбца, и каждой строке соответствует особое
представление, поэтому это определяет уникальность смысла базовой
модели применительно к каждой строке, каждая ячейка инфраструктуры уникальна, т. е. любой метаобъект не может появляться более
чем в одной ячейке.
x Бизнес-объект может встречаться только в ячейке А2.
x Объект данных может встречаться только в ячейке А3.
x Бизнес-процесс может встречаться только в ячейке В2.
x Прикладная функция может встречаться только в ячейке В3.
Следовательно, инфраструктура информационных систем служит
удобной классификационной схемой или «периодической таблицей»
для информационных объектов. Подобно химическим элементам, эти
объекты могут быть соединены множеством способов для создания
структур или информационных систем, требуемых предприятию.
Следствием этого правила является то, что отличающимся ячейкам
свойственны свои собственные методы и различные графические
34
представления. Это следствие объясняет изобилие формализмов, используемых при разработке информационных систем, появившихся
за многие годы. Все они, вероятно, соответствуют некоторым целям,
но каждый из них рассматривает различный набор положений и ни
один из них, по сути, не является полностью адекватным. К тому же,
когда формализм любой ячейки, расширяясь, встраивает обозначения
из других ячеек в попытке обогащения своего набора возможностей и
средств, это усложняет проблему разработки и может привести к непреднамеренной субоптимизации других независимых переменных.
Например, в некоторых разработках приложений может показаться
удобным изобразить хранение данных в диаграммах потоков данных
для ячейки В3. При этом, возможно, не совсем ясно осознается, что
хранение данных представляет собой набор атрибутов объектов логической модели данных ячейки А3 и появляется риск, что дизайнер
может создать соответствующий файл в соответствии с локальными
требованиями процесса. В этом случае целостность данных, определенная логической моделью данных, может быть подвергнута риску и
мало вероятно, что эти данные могут быть использованы любыми
другими процессами.
Уникальность каждой ячейки также объясняет изобилие возникающих методологий. Обычно казалось, что любая конкретная методология избирает некоторую последовательность создания некоторого
набора ячеек. Эта последовательность определяет систему оценки,
применяемую при принятии компромиссных решений разработки
внутри ячейки, т. е. структура текущей ячейки может быть установлена на основе решений, принятых в ячейках, находящихся выше,
ниже или в той же строке. Ячейка, которую методология определяет
первой для создания, вероятно, окажет сильное влияние на выбор
компромиссных решений для структуры последовательно конструируемых ячеек.
Правило 6. Интеграция всех моделей ячеек одной строки устанавливает полную модель для представления этой строки. Это
правило исходит из того факта, что любая одна ячейка любого столбца является только одной отдельной абстракцией реальности. Следо35
вательно, набор всех ячеек данной строки представляет собой полное
описание реальности для представления этой строки. Смысл этого правила состоит в том, что при включении дополнительного столбца каждое описание новой ячейки должно быть совместимым с представлением этой строки, т. е. каждая ячейка в данной строке может быть определена и имеет релевантность, независимую от любой других ячеек в
строке. Тем не менее, каждая ячейка представляет собой одну абстракцию одной и той же реальности. Следовательно, как минимум, каждая
ячейка связана с каждой другой ячейкой в одном и том же ряду. В некоторых случаях может даже существовать зависимость от других ячеек в строке. В таких случаях изменения в структуре одной ячейки будет, вероятно, оказывать некоторое влияние на другую зависимую
ячейку. Это справедливо не только относительно строки, но также
определенно справедливо для столбца, где по определению существует
зависимость между любой одной ячейкой и ячейками, расположенными выше и ниже ее. Таким образом, изменение в любой данной ячейке
будет, вероятно, влиять на ячейку выше и ниже и потенциально на другие ячейки в той же строке, где существует зависимость.
Стоит заметить, что если бы природа зависимости между ячейками
могла бы быть понятной и аккумулируемой в репозитории совместно
с моделью ячейки, это бы могло составить очень мощную возможность для понимания полного влияния изменения на любую из моделей, если не возможность для управления фактическим распространением изменений.
Правило 7. Логика является рекурсивной. Логика инфраструктуры может быть использована для описания фактически чего угодно, несомненно, чего угодно, что имеет владельца, дизайнера и изготовителя, которые применяют материал, функцию и геометрию. Рассматриваемая логика первоначально была воспринята посредством
исследования процессов конструирования и сооружения зданий.
Позже она была подтверждена исследованиями проектирования и
производства авиатехники. Впоследствии она была применена к
предприятию. В настоящей работе она применяется к информационным системам. Подобным образом она могла бы быть применена к
изготовлению средств CASE.
36
Ключевые термины
Архитектура
информационных Модель процессов
систем
Модель сети
Базовая модель столбца
Модель системы
Владельцы системы
Модель цели-средства-цели
Дизайнеры систем
Организационная схема
Изготовители систем
Пользователи системы
Информационные работники
Представление архитектуры
Модель времени
Системный аналитик
Модель данных
Технологическая модель
Модель предприятия
Функциональная модель
Контрольные вопросы
1. Назовите шесть аспектов рассмотрения информационной системы.
2. Назовите пять уровней представления инфраструктуры архитектуры информационных систем.
3. Назовите пять категорий лиц, заинтересованных в информационной системе организации.
4. Дайте определение архитектуры информационных систем.
5. Определите, к каким ячейкам инфраструктуры архитектуры информационных систем относятся методы моделирования DFD,
IDEF0, IDEF1X?
6. Назовите шесть правил инфраструктуры архитектуры систем.
7. Дайте определение базовой метамодели инфраструктуры.
8. В чем заключается уникальность каждой ячейки инфраструктуры?
9. Почему столбцы инфраструктуры архитектуры информационных систем обладают свойством неупорядоченности?
10. Что символизирует каждая строка инфраструктуры?
11. Каким свойством обладает базовая модель для каждого столбца
инфраструктуры архитектуры информационных систем?
12. Что определяют совместно все модели одной строки инфраструктуры?
13. Что определяют модели всех ячеек столбца инфраструктуры?
37
14. В какой последовательности развивается процесс разработки
информационной системы в контексте инфраструктуры архитектуры
систем?
15. В чем состоит свойство аддитивности применительно к строкам инфраструктуры архитектуры информационных систем?
16. Приведите примеры моделей для ячеек инфраструктуры.
17. Назовите причины, обусловливающие важность включения аспектов времени, людей и мотивации при рассмотрении архитектуры
информационной системы?
18. Определите суть субоптимального подхода к информатизации
предприятия и его основной недостаток.
Глава 2. РАЗРАБОТКА ИНФОРМАЦИОННЫХ
СИСТЕМ И МЕТОДОЛОГИИ
Первые разработки компьютерных информационных систем относят к началу 1950-х гг., когда появились первые программные приложения, облегчающие деятельность работников в организациях. Выполненные работы и накопленный опыт, теоретические предположения и обобщения продолжительного и сложного периода начального
становления этого вида деятельности явились основой для формирования некоторого подхода к разработке информационных систем, которую сегодня называют традиционной. Современные подходы к
разработке информационных систем начали возникать в 1980 г. С тех
пор эта область существенно продвинулась вперед. Результат современных достижений – методологии разработки систем и стандарты,
способны обеспечить целенаправленное и эффективное управление
для придания необходимых свойств информационным системам
предприятий, объективно требуемых условиями глобальной конкуренции. Тем не менее, традиционный подход к разработке все еще
находит применение благодаря простоте его понимания. Несмотря на
то, что эта глава акцентирует свое внимание на анализе и дизайне не
следует все же забывать, что программирование обычно составляет
большую часть разработки систем.
2.1. Разработка систем
Термин «разработка систем» используется для обозначения всего
процесса создания информационной системы управления. Многочисленные типы этих систем включают в себя системы здравоохранения, администрирования приема амбулаторных больных, системы
страхования, печатающие уведомления о продлении страховых полисов, и др. Качество использования информационных систем
обычно является жизненно важным для организации. Если компьютерная система, манипулирующая выставлением счетов-фактур,
имеет недостатки, то клиенты компании могут недополучить доку39
менты для оплаты, что может стоить ей репутации, и недополучения
дохода от продаж.
В процессе разработки информационной системы участвуют как
программисты, которые пишут программы, так и системные аналитики, которые делают все остальное, например, исследуют требования
для новой системы. Однако в небольших проектах можно также часто
встретить аналитиков-программистов, которые выполняют как анализ, так и программирование.
Разработка систем, как предполагается, рассматривает все элементы, составляющие информационную систему, а не только аспекты
информационных технологий. Она включает в себя не только аппаратные и программные средства, но также и такие элементы как формы документов, офисную обработку, документацию и подготовку
персонала (пользователей системы). Когда внедряется небольшая система, пользователи, как правило, работают с нею сами, например,
посредством ввода данных с персональных компьютеров. В больших
системах часть работы для пользователей может выполнять подразделение вычислительных работ, например, пакеты форм, поступающие от пользователей, могут вводиться в компьютер персоналом подготовки данных. Однако использование такого персонала продолжает
уменьшаться. Существуют также полностью ручные офисные системы. Так, например, ассоциация ручных бизнес-систем продвигает
ручные системы для небольших организаций. Эти системы основаны
на применении специальных канцелярских принадлежностей, таких
как наборы конторских форм с безугольным копировальным слоем.
На противоположном конце шкалы возможных систем находятся
высокоавтоматизированные системы, которые требуют совсем небольшого вмешательства человека. Технические системы, такие как
компьютеризированные схемы управления стиральных машин также
часто попадают в эту категорию. В таком случае пользователю достаточно только выбрать требуемую последовательность операций стирки и компьютерный процессор будет осуществлять управление
наполнением водой, нагревом и т. п. На практике, конечно, большинство систем организаций в значительной степени вовлекают в свою
40
сферу, как технологии, так и людей. Однако некоторый компьютерный персонал и учебники предпочитают сосредотачиваться на технических аспектах, в частности, на программном обеспечении не принимая во внимание административного и человеческого фактора. В
таком ограниченном контексте разработка программ и разработка систем становятся почти синонимами.
2.1.1. Традиционная разработка
Традиционная разработка систем связана с проблемами создания
административных информационных систем. Обычная информационная система организации, такая как обработка заработной платы в
органах местного управления может быть обширной и сложной. На
разработку большой компьютерной программной системы может потребоваться много человеко-лет, и стоимость ее может составлять более миллиона долларов. В связи с такой высокой стоимостью и большими сроками разработки заказных систем и были разработаны стандартные прикладные пакеты программ, например, для таких широко
распространенных приложений как заработная плата. Хотя эти пакеты значительно снижают расходы пользователя, они все равно должны разрабатываться поставщиками программных средств. Кроме того, работа, связанная с выбором и внедрением пакетов для большой
организации все еще может оставаться значительной. В противоположность большим системам разработка малых систем может занять
несколько часов. Распространенным примером этого может служить
внесение изменений в систему электронных таблиц для изменения
формата анализа потоков денежных средств. Необходимо отметить,
что традиционная разработка систем не является легко применимой к
некоторым новым областям информационных технологий, таким как
экспертные системы.
2.1.2. Современная разработка
Для того чтобы гарантировать, что система будет создана к установленному времени в пределах выделенных денежных средств и бу41
дет соответствовать определенному качеству, важно, чтобы персонал,
разрабатывающий систему, следовал некоторой определенной формальной процедуре. Эти формальные процедуры называют методологиями разработки систем. Методологии особенно важны, когда над
одним проектом работает несколько человек в период, исчисляемый
годами. При этом они, в основном, имеют дело с верным и стандартизированным специализированным приложением, использующим
опробованный метод для проведения системного анализа, дизайна и
программирования. Методологии также стандартизируют и улучшают документацию и управление компьютерными проектами.
В нескольких случаях традиционный подход к разработке систем
также был стандартизирован для формирования методологий.
Например, в традиционной методологии разработки систем NCC
предусмотрены стандартные формы для определения содержания таких документов как заказ на покупку, требование на материалы. Таким образом, системный аналитик может заполнять эти формы в процессе исследования системы.
Следует предостеречь, что вся тема предмета методов разработки,
подходов и методологий может породить значительную дискуссию,
иногда горячий спор между теоретиками и практиками в области информационных технологий. Ученые и компьютерные консультанты
изучают «сравнительную методологию», т.е. «за» и «против» различных методологий. Следует отметить, что выбор методологии является
основополагающим стратегическим решением в компании. Методологии устанавливают на многие годы модель работы персонала по
разработке систем. Кроме того, каждая методология имеет своих собственных пропагандистов, а учебные курсы, консалтинг и публикации, продвигающие конкретные методологии, являются в то же самое
время, источниками дохода.
Необходимо также отметить следующее положение, что методологии (систематизированные и стандартизированные методы работы) не
ограничиваются только информационными технологиями. Они также
существуют в аудите, применяются для проверки бухгалтерской деятельности, в технической, производственной и других областях,
42
например, в автомобильной, судостроительной, строительной промышленности и т.п.
2.1.3. Жизненный цикл разработки систем
Традиционные информационные системы ранних 1970-х гг. обычно были написаны на языке программирования COBOL и выполнялись на компьютерах мэйнфреймах. Типичная небольшая система того периода могла выводить на печать обобщенные данные о продажах компании для отдела маркетинга. Один из выходных документов,
например, мог показывать итоги продаж в разрезе географических
районов. Система могла состоять из десяти программ, и трудоемкость
ее составления могла составлять двенадцать человеко-месяцев работы по анализу и программированию. Часть этой работы, допустим,
восемь человеко-месяцев, могла быть программированием. Такие
проекты могут иметь место и сегодня, и они часто решаются подобным образом. Такая система могла разрабатываться в соответствии с
традиционным жизненным циклом, который представлен на рис. 2.1.
Благодаря своему внешнему виду представленная схема известна как
водопадная модель. Как видно из этой модели, основная идея этапа
анализа состоит в определении требований и сборе относящихся к
делу фактов. После этого может быть сконструирована и запрограммирована система, в частности, программа. Затем эта программа тестируется (испытывается) до применения ее пользователями. Результирующим выходом процесса разработки является программное приложение, готовое для применения, а также относящаяся к нему документация, такая как руководство пользователя системы.
Очень важно осознавать существование выходов для каждого этапа модели «водопад», т. е. выход представляет собой документацию,
которая умеренно формальна и в то же самое время естественна для
бизнес-пользователей и персонала информационных технологий.
Формальность подразумевает не больше чем представление документации в виде подобном учебникам по бизнесу и техническим учебникам. Документация каждого этапа часто представляет собой множе43
ство страниц, описывающих существующую или предполагаемую систему. Традиционная документация на систему, по общему мнению,
характеризуется сверхмногочисленностью слов и малочисленностью
схем. Кроме схем документация часто содержит копии деловых документов, распечаток выходных документов и форматов экранных
форм. Документация, связанная с производством полностью новой
системы, могла бы составлять несколько больших томов, большинство из которых создаются системным аналитиком.
Анализ
Дизайн
Программирование
Тестирование
Рис. 2.1. Упрощенное представление традиционного жизненного цикла
Основные этапы традиционного цикла разработки подробно представлены на рис. 2.2 и объясняются ниже.
Инициирование. Для того чтобы определенный проект мог быть
начат, должно существовать некоторое основание для выбора одного
проекта, а не другого и возможность наделения аналитика полномочиями для выполнения этой работы. Пределы компетенции проекта
очерчиваются письменным разрешением, которое содержит намеченное в общих чертах содержание предполагаемой работы. Инициирование проекта может происходить от нескольких источников, таких
как долгосрочное бизнес- и ИТ-планирование или специальные запросы пользователей. В обычной компании менеджер отдела может
прийти к выводу, что существующая ручная процедура является
слишком трудоемкой, и запросить дополнительную компьютерную
поддержку у ИТ отдела. Фирмы по разработке и (или) продаже программного обеспечения могут систематически производить поиск новых программных продуктов, проектов и рынков и, осуществляя про44
движение своей продукции, заинтересовывать организации в осуществлении изменений в существующих информационных системах.
Любой ИТ-проект должен быть, конечно, совместим с ИТстратегией организации. ИТ-стратегия, или долгосрочный план информационных технологий определяет такие аспекты как общая природа, приоритетность и временные рамки проекта.
Анализ осуществимости выполняется для предложенного компьютерного приложения. Это относительно быстрое исследование.
Исследуются различные варианты для новой системы, в частности,
их вероятная стоимость и выгоды от применения. Например, бухгалтерский отдел может иметь желание узнать вероятную стоимость и
время, требуемое для создания новой системы управления затратами.
Обычно существует возможность создать дешевую («сляпанную
наспех») версию системы или дорогую («роскошную») версию.
Инициирование
проекта
Анализ
осуществимости
Анализ
Дизайн
Изготовление
Контроль качества
системы
Внедрение
Сопровождение и
эксплуатация
Замещение новой
системой
Рис. 2.2. Подробное представление традиционного жизненного цикла
45
Другие варианты могут быть связаны со сравнением версии, реализованной на мэйнфрейме, и противоположной ей, реализованной
на локальной сети. Иногда один из вариантов выбора может заключаться не в продолжении выполнения проекта, а, возможно, в продолжении использования старой, уже существующей системы организации. Область определения или масштаб любой работы является
ключевым фактором, который должен быть установлен на ранних
стадиях проекта, обычно она определяется на этапе анализа осуществимости. Например, включает ли предполагаемая система управления производством завода закупку исходных комплектующих материалов? Основным выходом этапа анализа осуществимости является
технико-экономический доклад (обоснование). Он используется как
менеджментом, так и пользователями при рассмотрении вариантов и
утверждении одного из них, возможно, с рекомендуемой модификацией.
Основной целью исследований осуществимости является определение того, стоит ли продолжать проект и какой способ является
наилучшим для его воплощения. Однако в случаях, когда работа является настолько важной или настолько простой, анализ осуществимости игнорируют. Это часто делают при обычном сопровождении
существующей системы, когда требуется осуществлять регулярные
изменения в выходных документах или экранных формах.
Анализ. Если проект признан осуществимым, системный аналитик исследует в подробностях существующую информационную систему организации и будущие требования. Исследования обычно выполняются посредством опроса (интервью) офисных служащих и
сбора информации, а также используемых ими форм документации.
Это делается потому, что предполагается, что многие из возможностей существующей системы также будут использованы в новой
улучшенной будущей системе. В некоторых случаях, конечно, на
предприятии может и не существовать старой системы и работа аналитика в этом случае состоит в определении требований к полностью
новой системе.
46
Основным выходом анализа является спецификация текущей системы и перечень будущих требований. Пользователи могут проверить, что аналитики правильно поняли и отразили в документации
текущую процедуру.
Дизайн. Основываясь на результатах этапа анализа, аналитик конструирует новую систему, включая в нее желаемые возможности, которые были определены как осуществимые.
Насколько представляют себе руководители и пользователи основным выходом дизайна системы являются изображения экранных
форм видеодисплейных терминалов и выводов на печать. Теоретически офисные процедуры и офисная работа также должны быть включены в дизайн, но на практике существует рыночная тенденция обходить такие положения. После этого пользователь проверяет предложенную систему. Любые исправления согласовываются и встраиваются в пересмотренную спецификацию системы, и компьютерный
персонал может продолжать разрабатывать систему.
Далее аналитик разрабатывает и специфицирует технически более
подробно требуемое программное обеспечение. Дизайн аппаратной и
программной системы требует досконального понимания таких технических областей как телекоммуникации и базы данных. Основным
выходом этого этапа для ИТ-персонала являются спецификации программ или модулей.
Изготовление. Программисты должны использовать спецификации программного обеспечения, разработанные аналитиками, для
написания требуемых программ на компьютерном языке, предположим COBOL, оговоренном стандартами ИТ-подразделения.
Альтернативно, программирование может присутствовать в небольшом количестве либо вовсе отсутствовать, когда в процессе изготовления используются программные пакеты. Однако некоторые
гибкие пакеты, в частности пакеты заработной платы и др., требуют
определения большого количества параметров для установки требований пользователя в программном обеспечении. Параметры могут
представлять собой либо опции, либо данные, которые устанавливаются для конкретного пользователя или на долгий период времени.
47
Примерами параметров может служить наименование работы пользователя, которое требуется указывать на каждой распечатке. Ставки
НДС, используемые при подготовке счета в системах продаж, являются другим примером параметров. Когда параметры являются обширными, их ввод через видеодисплейные терминалы должен рассматриваться как процесс, сходный с программированием. Ввод параметров обычно осуществляется системным аналитиком. Аналитики
также пишут руководства для пользователей, которые объясняют, как
следует пользоваться системой.
Контроль качества системы. Аналитик подготавливает планы и
данные для тестирования системы. Это подразумевает установку
компьютерных файлов, содержащих, скажем, фиктивные данные заказов на продажу. Они используются для доказательства того, что
программы могут создавать правильные результаты или в случае гибких пакетов, что параметры были корректно введены. На ранних этапах тестирования обычно обнаруживается множество ошибок. Они
могут включать в себя ошибки в наименованиях заголовков выводов
на печать, ошибочные итоговые данные для показателей продаж или
отказ выполнения и аварийное завершение программ. После внесения
всех исправлений окончательный тест должен дать совершенные результаты Контроль качества системы – это больше чем тестирование.
Он также, например, включает проверку документации на ошибки и
пропуски. В конце этого этапа или во время внедрения пользователи
должны отдельно осуществить проверку системы. Это делается для
того, чтобы гарантировать, что система соответствует требованиям и
больше не содержит ошибок.
Внедрение. На этом этапе аналитик руководит установкой аппаратных и программных средств системы и обучает пользователей
применять ее. В некоторых случаях это может быть объемная задача,
например, когда внедряется система розничной торговли во многих
различных магазинах отделений компании. Внедрение часто рассматривается отдельно от разработки.
Эксплуатация. Успешная эксплуатация является скорее основной
целью цикла разработки систем, а не частью его. Информационные
48
системы организаций могут иметь эксплуатационный срок службы,
измеряемый несколькими годами. Привлечение аналитиков и программистов к самой эксплуатации не требуется. Однако их участие
необходимо для сопровождения и поддержки.
Анализ функционирования внедренной системы. Представляет
собой анализ проекта, который выполняется несколькими месяцами
после того, как система была разработана и внедрена. Идея такого
анализа состоит в определении любых нерешенных проблемных областей и возможностей. Кроме того, должна быть сделана проверка
того, что затраты и выгоды, идентифицированные на этапах анализа
осуществимости и дизайна, претворены в жизнь как предполагалось.
Это дает возможность извлечения уроков для будущей работы по
разработке систем.
Сопровождение. Аналитики обеспечивают исправление любых
недостатков и включение новых требований в систему. Через несколько лет объем работ по сопровождению может легко превысить
объем работы по разработке начального программного обеспечения.
Как указывается во многих источниках, очень часто утверждается,
что в среднем 80% так называемой работы по разработке систем в
действительности составляет сопровождение. Каждая работа по сопровождению, такая как совершенствование автоматизированных
расчетов по социальному страхованию, должна также проходить через основные этапы разработки систем, включающие анализ, дизайн,
изготовление и контроль качества. Отличие состоит в том, что сопровождение обычно требует модификации существующей документации и программных кодов, а не создания их в полном объеме.
Поддержка – это важная деятельность, которая тесно связана с сопровождением и иногда неотличима от нее. Примером поддержки является консультирование аналитиком пользователя об использовании
не периодически применяемых средств, наподобие обработки конца
года в системе заработной платы.
Замещение. Под влиянием таких факторов как продолжительно
проводимые изменения, программное обеспечение системы становится все более трудоемким в поддержке и все более устаревающим.
49
Трудовые затраты
(в человеко-днях в месяц)
В конце концов, становится существенным решение вопроса замещения системы. Классическим примером этого являются системы 1960х гг., написанные на языках программирования 2-го поколения (ассемблеры), которые были замещены системами 3-го поколения (такими как COBOL) в 1970-х гг. Эти системы, в свою очередь, были
замещены пакетами или системами языков 4-го поколения в 1980-х
гг. Таким образом, замещение приводит к повторению рассмотренных выше шагов через каждые несколько лет, и системы повторяют
жизненный цикл.
На рис. 2.3 представлены трудовые затраты, требуемые для традиционного жизненного цикла. Работы по сопровождению продолжаются многие годы и в итоге обычно превышают трудозатраты по разработке. Вся работа аналитиков и программистов в жизненном цикле,
в общем, может составлять от нескольких человеко-месяцев для небольших информационных систем и десятки человеко-лет для больших административных систем.
Дата
внедрения
Осуществимость
Анализ Дизайн
Изготовление
Контроль
качества
системы
Сопровождение
Время (месяцы и годы)
Рис. 2.3. Распределение трудозатрат
в традиционном жизненном цикле
Представленное выше описание традиционного жизненного цикла,
рассмотрено только в общих чертах. Существуют многочисленные варианты жизненного цикла и его подэтапов, описываемые в существу50
ющей обширной литературе по этой теме. Применяемая при этом терминология очень изменчива. Например, термин «этап анализа», используемый в данной работе, часто называют «исследованием», термин
«этап изготовления» иногда называют «построением» или часто просто
«программированием». «Дизайн системы» может быть тем же самым
что и «план системы» или «спецификация системы» и т.п.
Общая идея, на которой основываются существующие модели
жизненного цикла, заключается в обеспечении правильности выполнения и документирования каждого этапа и подэтапа до осуществления действий следующего. То есть к каждому этапу или подэтапу
применяются проверки контроля качества; их даже могут применять
к части работ подэтапа, такой как спецификация программ. Например, не имеет смысла выполнять любую работу дизайна до тех пор,
пока пользователи не подтвердят, что требования к будущей системе
определены корректно.
Необходимо отметить, что документация, создаваемая на каждом
этапе жизненного цикла, имеет только временное или историческое
значение. Такая документация играет такую же роль, как и строительные леса, используемые для возведения здания, – они являются
необходимой частью процесса, но не требуются надолго.
Вышерассмотренный подход к жизненному циклу разработки информационных систем тяготеет к предполагаемому использованию
языков третьего поколения, таких как COBOL. Однако он может быть
модифицирован для других методов разработки систем – использованию программных пакетов, которые существенно снижают объем работ по программированию.
2.1.4. Стандарты
Традиционный жизненный цикл разработки часто стандартизируют, по крайне мере, частично. Это означает, что в любом компьютерном отделе организации существуют, например, стандартные формы
для перечисления сведений о данных, которые должны храниться в
компьютерных файлах. Существующие стандарты представляются в
51
руководствах и в большинстве являются, скорее, бюрократическими.
Кроме форм, которые необходимо использовать, стандарты содержат
такие материалы как обозначения, которые необходимо использовать в
схемах, и приводят перечень заголовков глав для таких документов как
спецификации текущей системы и будущих требований. В сущности,
руководства стандартов разъясняют аналитикам и программистам как
они должны выполнять свою работу. Если все системы создаются по
одному и тому же стандарту, то многое становится совместимым, является ли это форматом отчета, выводимого на печать, или форматом
экранных сообщений об ошибках или содержанием спецификаций. Это
значительно облегчает работу менеджеров по отслеживанию продвижения работы по разработке системы.
Использование системы также значительно облегчается, если
пользователи и аналитики знают, что дата составления компьютером
отчета всегда печатается в правом верхнем его углу независимо от
лица, разработавшего или запрограммировавшего этот отчет. Отметим, что методология разработки систем является только одним важным примером стандарта, она должна использоваться совместно с
другими стандартами. Методологии разработки систем, например не
определяют стандартный формат для нумерации возможных экранных форм и выводов на печать, создаваемых системой, например,
ЭФ07 для седьмой экранной формы системы журнала продаж.
Первые стандарты, включающие в себя идеи унификации работ и
представления результатов при разработке информационных систем,
появились в конце 1960-х гг. – начале 1070-х гг. Вполне понятно, что
с развитием области разработки информационных систем стандарты
непрерывно совершенствуются. Существующая в нашей стране государственная система стандартов предусматривает для этих целей
стандарты серий ГОСТ 24 – «Единая система стандартов автоматизированных систем управления» и ГОСТ 34 – «Стандарты по информационным технологиям». Так, например, ГОСТ 34.601-90 «Автоматизированные системы стадии создания», устанавливает следующие
стадии и этапы создания.
1. Формирование требований
52
1.1. Обследование объекта и обоснование необходимости создания
1.2. Формирование требований пользователя
1.3. Оформление отчета о выполненной работе и заявки на разработку (тактико-технического задания)
2. Разработка концепции
2,1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских работ
2.3 Разработка вариантов концепции системы и выбор варианта
концепции системы, удовлетворяющего требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание
3.1. Разработка и утверждение технического задания на создание
4. Эскизный проект
4.1. Разработка предварительных проектных решений по системе и
ее частям
4.2. Разработка документации на систему и ее части
5. Технический проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на систему и ее части
5.3. Разработка и оформление документации на поставку изделий
для комплектования системы и (или) технических требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее части
6.2. Разработка или адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации к вводу системы в действие
7.2. Подготовка персонала
7.3. Комплектация системы поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
7.4. Строительно-монтажные работы
53
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение
8.1. Выполнение работ в соответствии с гарантийными обязательствами
8.2. Послегарантийное обслуживание
При этом для каждого из установленных таким образом этапов он
также описывает содержание соответствующих ему работ.
Появившийся значительно позже отечественный стандарт ГОСТ Р
ИСО МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем», являющийся аналогом ISO/IEC 15288:2002 приводит следующие стадии жизненного
цикла системы, которые рассматриваются только в качестве примера.
1. Стадия замысла.
2. Стадия разработки.
3. Стадия производства.
4. Стадия применения.
5. Стадия поддержки применения.
6. Стадия прекращения применения и списания.
В следующей версии этого же стандарта от 2008 года (ISO/IEC
15288:2008) примеры стадий жизненного цикла отсутствуют.
Таким образом, как это очевидно, существующие современные
стандарты, определяя на высоком уровне обобщенные требования унификации процессов разработки систем, со временем передают все
больше прав дальнейшей детализации требований к процессу разработки на уровень корпораций, компаний, министерств и ведомств. Основная причина ослабевания требований стандартов к процессу разработки
систем, скорее, обусловлена с достижениями развивающейся теории и
большим накопленным практическим опытом применения методологий
разработки информационных систем. Как можно будет убедиться из
материала раздела 2.3, большой накопленный опыт практического применения методических руководств, предопределяющих заранее ход
54
процесса любой разработки, показал, что не во всех жизненных ситуациях предлагаемая каждым из них траектория процесса ведет к позитивному результату. Поэтому на самом деле, если организация предполагает осуществлять разработку некоторой информационной системы,
то желательно предварительно, руководствуясь основными принципами разработки, выбрать подход и наметить индивидуальный путь, которому она будет следовать в этом процессе, а также методы и средства
CASE, которые она будет применять при движении к намеченной цели.
2.1.5. Ограничения традиционного жизненного цикла
Традиционный подход жизненного цикла разработки систем часто
критикуют, но его разновидности все еще используются ИТ персоналом, как для бизнес так и для технических систем. Они также нравятся бизнес пользователям, не имеющим IT образования. Кроме того
действуют все еще довольно много старых систем, и их документация
по-прежнему традиционна. Типичная критика традиционного жизненного цикла разработки систем приведена ниже.
Излишняя простота. Традиционный жизненный цикл разработки
систем очень ограничен. Например, он представляет слишком упрощенную версию выполнения разработки или как это должно происходить. Традиционный жизненный цикл разработки систем, как описано выше, может работать достаточно хорошо при условии разумного применения к компьютерным проектам среднего размера с трудозатратами до нескольких человеко-лет, и при условии скромного сопровождения проекта. Было бы иллюзией полагать, что существует
одна универсальная практическая методология, которая может охватить все ИТ приложения от общегосударственной системы социального обеспечения до настольной экспертной системы.
Высокая неопределенность. Даже в своем подробном виде традиционная модель жизненного цикла разработки является, как правило, не более чем набор общих руководящих принципов о том, как
осуществлять анализ, проектирование и программирование бизнес
системы. Это означает, что требуется значительный опыт, чтобы
55
применить его успешно. Некоторые традиционные руководства стандартов жизненного цикла разработки систем давали крайне подробные инструкции о процедурах, которым необходимо следовать для
создания систем и документации.
Отсутствие строгости или структуры. Традиционные спецификации не являются строгими. Они слабо структурированы, неоднозначны, и не полны. Многие желательные подробности в эти спецификации не были включены. Это, вероятно, справедливо для большей
части традиционной разработки. Хотя можно было бы сказать, что
это было только из-за плохого применения традиционных методов и
плохого контроля качества, а не дефекта самих методов.
Отсутствие графического интерфейса. Классические спецификации, как правило, склоняются к использованию текста, а не графики для спецификаций. Текст часто не подходят для определения
сложных административных и компьютерных процессов. Это приводит к неожиданным объемным документам, которые никогда не читают. Это, конечно, справедливо для многих проектных спецификаций. Однако критика, вероятно, неприменима в целом. Некоторые
бизнес-системы 1950-х – 1970-х годов широко применяли схемы,
например, системы, использующие стиль Национального вычислительного центра Великобритании (NCC). Некоторые бизнеспользователи рады читать и конструктивно критиковать разумные
технические текстовые спецификации. Они также считают современные спецификации, широко использующие объемные схемы, неестественными и трудно понимаемыми.
Отсутствие структурированных методов. Традиционные методы системного анализа и проектирования не включают в себя структурированные методы. Это в целом верно, так как эти методы были
только изобретены в конце 1970-х годов. Некоторые люди, однако,
привносят структурированные методы в традиционные рамки.
Недостаточное внимание на данные. Это контрастирует с современным мышлением. Современные представления уделяют значительное внимание данным, используемым в информационной системе, а не процессам, таким как вычисления, которые используют эти
56
данные. Это, скорее, правда, что люди традиционно сосредоточивались на процессах за счет данных. Иногда делались попытки для исправления этого.
Отсутствие стандартов. Традиционная разработка лишь в общих
чертах стандартизирована на практике. Различные предприятия имеют разные детальные стандарты. Различные стандарты могут часто
встречаться в той же организации. Это может также относиться к современным структурированным методологиям. Кроме того, стандарты охватывают больше чем методологии разработки.
Плохой контроль качества. Документация и контроль качества
(проверка работы), часто усечены. Это может также быть отнесено и
к современным структурированным методологиям. Это в основном
вопрос дисциплины.
Плохое обновление. Традиционные системы и программная документация часто не обновляются должным образом, когда происходит изменение системы. В этой ситуации документация может ввести
в заблуждение и стать бесполезной в течение нескольких месяцев.
Это, конечно, верно, что поправки представляли собой отдельные документы и часто не включались в исходные спецификации из-за затрат на перерисовку схем и перепечатывание текста без современных
программных средств. Результат представлял собой исходную спецификацию с пятьюдесятью отдельными документами, вносящими
поправки в исходную спецификацию. Это отражает отсутствие программных средств в 1960-х и 1970-х, а не какую-либо вину в методологии. Структурный анализ и дизайн без применения программных
средств, как правило, страдают от тех же проблем.
Отсутствие четко определенных результатов разработки, приводящее к трудностям управления. Традиционная разработка плохо разделяется на этапы и задачи проекта. В тех случаях, когда проект разделяется на разделы работ, они слишком широко и плохо
определены. Поэтому невозможно точно определить, насколько полно выполнен проект, находящийся на промежуточной стадии. Что не
хватает традиционному анализу и проектированию, это набор частных «выходных под-результатов», т.е. разделения проекта на опреде57
ленные небольшие пакеты работ, которые могут быть завершены
один за другим. Это отсутствие четких частных результатов затрудняет управление проектом и некоторые говорят, что традиционная
разработка неуправляема. Это частичная правда. Методологии, основанные на традиционном анализе и проектировании, вероятно, не
определяют выходные результаты, как это четко определено в современных «ухоженных» пакетах, подобно SSADM.
Слишком долго и дорого. Традиционный подход к разработке
может занять годы, для создания новых больших систем. Как следствие затраты на разработку очень высоки. Это, конечно, верно. Однако это также справедливо для современных методологий, когда задача решаются с неадекватными программными средствами. COBOL
программирование, например, может быть очень утомительным независимо от того используются ли современные структурированные
методы или методы старого стиля. Современные средства разработки
программного обеспечения могут значительно улучшить время разработки, как старых, так и новых методологий.
Как видно наиболее распространенные критические замечания на
традиционную разработку систем являются преувеличенными. Однако важно осуществить оценку по вышерассмотренным пунктам, если
намечается выполнение проекта, используя версию традиционного
подхода. Три наиболее серьезные недостатка, упомянутые выше
включают в себя отсутствие строго определенных результатов, слишком большой акцент на процессах в ущерб данным, а также отсутствие структурированных методов. Как уже отмечалось с осторожностью, большинство из этих недостатков могут быть преодолены в небольших проектах.
Однако нет никаких сомнений в том, что легче быть небрежным,
предпочтя традиционный жизненный цикл, и отсутствие руководящих указаний о том, как действовать. В противоположность этому
современные методологии дают очень подробные процедуры для
разработки систем. Однако в обоих случаях их применения необходима дисциплина. Некоторые наблюдения показывают, что некоторые сотрудники, использующие современную разработку, как прави58
ло, склоняются к возврату к традиционным методам. С другой стороны, другие сотрудники, использующие традиционные подходы, склоняются в сторону современных методологий, медленно принимая
структурированные методы. Это означает, что граница между традиционными и современными подходами размыта на практике и постоянно меняется. Опыт разработки систем, с использование как традиционных, так и современных методов более двадцати лет, был умеренно обнадеживающим. Как правило, появлялись процедуры разработки, и создавалась обширная документация по стандартам для всех
стадий разработки. Тем не менее, во многих организациях не существуют даже элементарные процедуры разработки и документация.
В основном люди писали (и продолжают) сложное программное обеспечение на основе словесных инструкций и лоскутных рукописных заметок, которые вскоре были отброшены. Кроме того, контроль качества
программного обеспечения был скудный. Это было подтверждено служащими, которые длительное время участвовали в разработке систем,
иногда в крупных организациях. Обычное оправдание для такого плохого состояния дел состояло в излишней бюрократичности методологий, традиционных или современных и в отсутствии времени для документации. Достаточно сказать, что низкокачественные процедуры разработки и отсутствие документации может привести к системам плохого качества, которые трудно и дорого поддерживать.
2.2. Методологии разработки систем
Современные методологии разработки систем реагируют на недостатки в традиционном жизненном цикле разработки систем. Они в
основном уделяют внимание аспектам анализа и дизайна, а не программированию, которое, в свою очередь, представляет обширную
область. Граница между дизайном системы и программированием не
совсем ясна и зависит от адаптируемой методологии и предпочтений
каждой организации. Иногда граница определяется природой проекта
и участвующим в нем персоналом. Содержание методологий в основ-
59
ном направлено на решение вопросов разработки применительно к
системам обработки транзакций и управленческих отчетов.
Как уже было упомянуто ранее, стандартизованные версии жизненного цикла разработки систем появились в 1970-х гг. Они представляли собой подробный и бюрократический способ вовлечения
аналитиков и программистов в выполнение многих этапов, таких как
анализ текущей системы и создание разнообразных документов стандартизованным способом. Однако в конце 1970-х гг. возник новый
подход, называемый структурным анализом и дизайном. Он был порожден более ранними и связанными идеями, которые составляют
основу структурного программирования, а также включал в себя идеи
из теории баз данных. Однако достаточно сказать, что структурный
анализ и дизайн был скорее подходом, чем методологией, т. е. другими словами, он представлял собой серию концепций и методов. По
существу, структурный анализ и дизайн применяет большее количество схем и делает большее ударение на анализе данных. Как подразумевает прилагательное «структурный», структурный анализ и дизайн влечет за собой планомерную и тщательную спецификацию бизнес-деятельности и программного обеспечения на последовательных
уровнях возрастающих подробностей.
Последующие разработки представляют собой комбинацию идей
структурного анализа и дизайна со стандартизованной терминологией, графическими системами обозначений и процедурами. Это привело к появлению структурных методологий в 1980-х гг., таких как
SSADM (Structured Systems Analysis and Design Method). Как и их
традиционные предшественники, структурные методологии описываются в объемистых руководствах и предписывают подробный способ анализа и дизайна систем. Однако они более требовательны к
разработчикам и точны.
Современные структурные методологии более податливы для автоматизации в форме автоматизированного рабочего места аналитика. Это означает, что аналитик может руководствоваться и получать
помощь непосредственно от компьютерной системы при подготовке
спецификаций. Применение традиционных и современных методоло60
гий обеспечивает выполнение первостепенного требования к разработке, гарантирующего, что проект информационной системы соответствует реальным потребностям предприятия, его долгосрочным
бизнес-планам и планам развития информационных технологий организации.
Существует много методологий, но практически широкую известность получили только некоторые из них. К ним относятся следующие.
x SSADM – Structured Systems Analysis and Design Methodology
(Методология структурного системного анализа и дизайна). Основная
методология разработки информационных систем в Великобритании
(рассматривается ниже).
x LSDM – Learmonth and Burchett Structured Development Method,
фирменная Британская методология, подобная SSADM.
x JSD – Jackson Systems Development (Системная разработка
Джексона), Британская методология.
x MERISE – французская промышленно производимая методология (рассматривается ниже).
x SADT – Structured Analysis and Design Technique (Метод структурного анализа и дизайна). Фирменная американская методология.
x STRADIS – Structured Analysis, Design, and Implementation of Information Systems (Структурный анализ, дизайн и внедрение информационных систем). Промышленно производимая американская методология.
x YSM – Yourdon Systems Method (Системный метод Йордана).
Влиятельная американская методология.
x IE – Information Engineering (Информационная инженерия).
Важная методология, которая отчетливо применяет стратегический
подход к анализу и дизайну (рассматривается ниже).
x OOA – Object-oriented analysis (Объектно-ориентированный
анализ).
x ISAC – Information Systems work and Analysis of Changes (Работа
информационных систем и анализ перемен). Методология, разработанная в Шведском королевском технологическом институте.
61
x ETHICS – Effective Technical and Human Implementation of Computer-based Systems (Эффективное человеко-машинное применение
автоматизированных систем).
x SSM – Soft Systems Methodology (Методология мягких систем).
x PI – Process Innovation (Технологическая инновация).
2.3. Эволюция методологий
В течение последних 40 лет разработка информационных систем
была в центре изучения и практики информационных систем. Этот
раздел рассматривает историю методологий разработки информационных систем, а также некоторые из тенденций и вопросов, касающихся разработки информационных систем, и показывает, как это все
отразилось в методологиях, и используется (или не используется) организациями. Обсуждение современного состояния области сопровождается обсуждением возможных будущих направлений.
2.3.1. Основные периоды эволюции
Современные результаты развития области разработки и методологий достигнуты во многом благодаря более чем 30-летней работе
Технического комитета TC8 Международной федерации по обработке информации (International Federation for Information Processing,
IFIP), который через свои рабочие группы (в особенности, но и не
только, WG 8.1 и WG 8.2) определил разработку информационных
систем своей главной работой и вкладом. Существуют также похожие
публикации четвертого издания, книги D.E.Avison and G.Fitzgerald.
Information Systems Development: Methodologies, Techniques and Tools.
4th edition, McGraw-Hill, Maidenhead. (2006), которая имеет 26-ти
летнюю историю. Размышления над этими результатами дают сегодня возможность, основываться на них, обновления наших знаний
для изучения истории методологий разработки информационных систем, а также пересмотра текущего состояния и выработки некоторых
предложений на будущее.
62
Деятельность, связанная с разработкой информационных систем,
существует так долго, сколько существуют компьютеры. Однако в
отличие от развития компьютерных технологий, которое было феноменальным, разработка общепринятого системного подхода или подходов для эффективного использования этих технологий шло медленнее, и это, возможно, было в некоторой степени ограничивающим
фактором, сдерживающим скорость прогресса в их использовании. В
некоторых других практических областях существует «один правильный способ делать что-то» – почему это не явилось тем же самым для
разработки информационных систем?
Рассматривая во времени некоторые из тенденций и проблем, связанных с разработкой информационных систем, можно выделить четыре периода: преметодологий, ранних методологий, методологий и
постметодологий. Все это можно бы быть воспринять как «полную
модель для разработки информационных систем», так как некоторые
организации в одних и тех же странах могут находиться в разных периодах развития, и как разные страны могут быть, в общем случае,
впереди или позади других. Таким образом, было бы рискованным
приписывать фактические даты этим «периодам», поскольку они
больше являются этапами практики разработки информационных систем. Тем не менее, можно предложить приблизительные десятилетия, в которых каждый из них был на первом плане в Северной Америке, Европе и Австралии. Нынешний период стал одним из наиболее
трудных для рассмотрения, так как полностью непонятно как это все
получится. В отличие от предыдущих периодов, мы не имеем преимущества в его оценке задним числом. Тем не менее, могло бы казаться, что этот период является, пожалуй, на удивление одним из
наиболее стабильных – методологии не создаются (или пересоздаются) как раньше, много методологий, предложенных в предыдущих
периодах, теперь не имеют последователей на практике и происходит
некоторое объединение в этой области. Там, где разработки не находится в некотором роде аутсорсинге, присутствует стремление к подходам, направленным на разработку продукта с большей скоростью и
гибкостью.
63
2.3.2. Период преметодологий
Ранние компьютерные приложения, примерно до создания технического комитета TC8 IFIP в 1976 г., были реализованы без применения явной методологии разработки информационных систем. Таким
образом, этот период можно охарактеризовать как преметодологический период. В эти ранние времена, акцент разработки компьютерных приложений делался на программировании. Поэтому потребности пользователей редко хорошо определялись, с тем нежелательным
последствием, что выполненный дизайн часто не соответствовал требованиями приложения. В центре внимания усилий было получение
чего-то, что работает и преодоление ограничений технологи, таких
как заставить приложение работать в ограниченном объеме памяти
компьютера. Особой проблемой было то, что имея хорошую техническую подготовку, разработчики редко были хорошими коммуникаторами. В качестве доминирующей «методологии» было произвольное
решение, основывающееся на опыте. Как правило, это приводило к
плохому контролю и управлению проектами. Например, было трудно
определить дату, на которую система должна стать действующей.
Приложения часто создавались с опозданием и с превышением бюджета. Программисты, как правило, были перегружены, и тратили
большую часть своего времени на исправление и улучшение нескольких приложений, которые были уже в рабочем состоянии. Эти проблемы привели к растущему пониманию желательности применения
стандартов и более дисциплинированного подхода к разработке информационных систем в организациях. Таким образом, были созданы
первые методологии разработки информационных систем. Хотя этот
период был общим во многих крупных европейских и североамериканских организациях 60-х, его характерные черты можно увидеть и в
настоящее время в некоторых компаниях, разрабатывающих приложения на персональных компьютерах.
64
2.3.3. Период ранних методологий
Как реакция на неудачи периода преметодологий в среде профессионалов возникало возрастающее понимание той части разработки
систем, которая касается анализа и проектирования и, следовательно,
потенциальной роли системного аналитика. Кроме того росло осознание того, что, по мере роста организации в размерах и сложности,
было бы желательно отойти от разовых решений к определенной
прикладной проблеме и приблизиться более к интегрированным информационным системам. Сформировалось также понимание желательности наличия принятой методологии для разработки информационных систем.
Эти размышления привели к эволюции жизненного цикла разработки систем (Systems Development Life Cycle, SDLC) или модели водопада, как подхода к разработке информационных систем. Это была
одной из первых методологий, хотя в то время она еще не была известна, как таковая. Она включала в себя фазы, процедуры, задачи,
правила, методы, принципы, документацию, учебные программы и
средства. Водопадная модель состояла из ряда этапов разработки, которые должны были выполняться последовательно. Эти этапы, как
правило, состояли из технико-экономического обоснования, исследования системы, анализа, проектирования, реализации, завершающиеся критическим анализом и сопровождением. Этот подход широко
использовался в 1970-х и даже немного в 1980-х годах, и он до сих
пор является основой для многих методологий.
Жизненный цикл разработки систем был хорошо испытан и проверен, и использование стандартов на рабочую документацию помогает
гарантировать, что предложения являются полными и что они понятны пользователям и компьютерному персоналу. Этот подход также
гарантирует, что пользователи обучены для применения системы.
Есть элементы контроля, и они, вместе с разделением проекта на фазы выполняемых задач с их результатами, помогают избегать пропущенных дат перехода с очередной фазы на последующую, и беспокойств в отношении того, что поставляется. Неожиданно высокие за65
траты и более низкие выгоды, также менее вероятны. Это дает возможность передавать аналитикам правильно сформированную, стандартную схему обучения, обеспечивая тем самым непрерывность
стандартов и систем.
Однако, не смотря на это, существуют серьезные ограничения на
этот подход наряду с ограничениями в способе его использования.
К некоторым потенциальным критическим замечаниям относятся следующие. Неспособность удовлетворения потребностей менеджмента
(за счет концентрации на отдельных приложениях на операционном
уровне организации). Неамбициозное проектирование систем (в связи
с акцентом на «компьютеризацию» существующей системы). Нестабильность (в связи с моделированием процессов, которые неустойчивы, в связи с частыми изменениями в предприятиях и их окружении).
Отсутствие гибкости (из-за ориентации процессов проектирования на
выход системы, что делает изменения в дизайне дорогостоящими).
Недовольство пользователей (из-за проблем с документацией и отсутствием возможности для пользователей ознакомиться с системой,
прежде чем она предстанет в рабочем состоянии). Проблемы с документацией (в связи с ее ориентацией на компьютеры, а не на пользователя и, с тем фактом, что эта документация редко бывает обновленной
до последнего состояния системы). Отставание приложений (из-за
объема работ обслуживания, когда делаются попытки изменения системы для отражения в ней потребностей пользователей). Допущения
разработки «зеленого поля» (из-за традиции компьютеризации при
помощи новой информационной системы существующей ручной системы). Такое предположение в настоящее время является неуместным, так как сегодня информационные системы в значительной мере
замещают, или интегрируются с существующими системами.
2.3.4. Период методологий
В ответ на одно или несколько из указанных выше ограничений
или критику жизненного цикла разработки систем появился целый
ряд различных подходов к разработке информационных систем, и
66
началось то, что может быть названо термином «эра методологий».
Методологии могут быть классифицированы на несколько направлений. Во-первых, это методологии, разработанные для улучшения традиционной модели водопада. Вторым направлением является предложение новых методологий, которые несколько отличаются от традиционной модели водопада (и друг от друга).
С 1970-х был проведен ряд разработок в методах и средствах, и
многие из них были объединены в методологии, иллюстрирующие
современную версию модели водопада. Различные конференции
CRIS (Comparative Review of Information Systems Design Methodologies) IFIP WG8.1 внесли важный вклад в этот процесс. Встроенные
методы включали в себя моделирование сущность-связь, нормализацию, построение диаграмм потоков данных, структурированный английский, диаграммы действий, структурные диаграммы и жизненные циклы сущностей. Разработанные средства включали программное обеспечение по управлению проектами, программные средства
словарей данных, репозитории систем, инструменты рисования и,
наиболее современные, автоматизирующее разработку, программные
(или системные) инжиниринговые CASE средства (которые теперь
существенно расширены, и их чаще называют наборами средств).
Объединение этих разработок вызвало некоторые критические замечания, рассмотренные для предшествующего периода. Смешанные
методологии Merise, SSADM и системный метод Йордана, можно
сказать, были обновленными версиями модели водопада. Позже движения метода инжиниринга, (сотрудничество IFIP WG 8.1 и WG 8.2)
развило далее практику сопряжения методов и приемов. Хотя эти
улучшения продвинули базовую модель к более современному состоянию, многие пользователи привели доводы, что негибкость жизненного цикла остается, и она препятствует наиболее эффективному использованию компьютерных информационных систем.
Альтернативные подходы, которые развивались в течение 1980-х и
за их пределами можно классифицировать в рамках ряда широких
тем в том числе: системные, стратегические, участвующие, прототипирующие, структурированные и основанные на данных. Каждая из
67
этих широких тем привела к одной или нескольким конкретным методологиям.
Системные подходы. Общая теория систем пытается понять природу систем, которые являются большими и сложными. Организации
являются открытыми системами, существующая взаимосвязь между
организацией и ее средой очень важна. Упрощая сложную ситуацию,
можно быть редукционистом, и тем самым искажать наше понимание
системы в целом. Наиболее хорошо известным подходом в информационных системах для решения этого вопроса является методология
мягких систем SSM. Она включает в себя методы, такие как рич пикче (карты разума), которые помогают пользователям понять организационную ситуацию, и, следовательно, указывают на области для
организационного совершенствования, за счет использования информационных систем.
Стратегические подходы делают акцент на предварительном
планировании, включенном в разработку информационных систем и
на необходимости общей стратегии. Это вовлекает высший менеджмент в анализ целей их организации. Эти подходы парируют возможность разработки информационных систем по частям. «Планирование
бизнес систем IBM» (IBM’s Business Systems Planning) является одним из первых примеров такого подхода и ре-инжиниринг бизнеспроцесса является частью этого общего движения.
Участвующие подходы подчеркивают роль всех пользователей и
роль технического специалиста может быть реализована другими заинтересованными сторонами информационной системы. Если пользователи, участвующие в анализе, проектировании и реализации информационной системы, релевантны своей работе, особенно если это принимает форму подлинного принятия решений, эти пользователи, скорее
всего, дадут новой информационной системе свое полное представление, когда она будет реализована, и тем самым увеличат вероятность ее
успеха. ETHICS подчеркивает природу непосредственного участия в
разработке информационной системы, следуя социотехническому движению и работе института Тависток (Tavistock Institute), и воплощает в
себе устойчивую этическую позицию.
68
Прототипирующие подходы. Прототип являются приближением
типа, который проявляет существенные черты окончательной версии
этого типа. Реализуя в начале прототип, аналитик может показать
входы пользователей, промежуточные этапы, и выходы системы. Это
не схемные приближения, которые, как правило, выглядят как абстракции или технически-ориентированная документация, которая
может быть не понята пользователям. Это фактические данные на
бумажном носителе или на экранах терминальных или рабочих станций. Инструментальные средства различных видов могут давать возможность проводить прототипирование. Они становятся все более и
более мощным за последние несколько лет. Быстрая разработка приложений является примером подхода, который воплощает прототипирование.
Структурированный подход. Структурированные методологии
основаны на функциональной декомпозиции, которая представляет
собой разбиение сложной проблемы на поддающиеся контролю единицы упорядоченным образом. Эти подходы, как правило, делают
ударение на методах, таких как деревья решений, таблицы принятия
решений, диаграммы потоков данных, структурные диаграммы данных, и структурированный английский и инструментах, таких как системные репозитории.
Подход, основанный на данных. В то время как структурированный анализ и дизайн подчеркивает процессы, анализ данных концентрируется на понимание и документирование данных. Это включает в
себя сбор, проверку и классификацию сущностей, атрибутов и отношений, которые существуют в исследуемой области. Даже если изменить приложения, уже собранные данные все еще могут иметь отношение к новым или пересмотренным системам и, следовательно, нет
необходимости в их повторном сборе и проверке. Информационная
инженерия, например, центрируется на подходе данных.
В 1990-х г. происходило то, что может быть воспринято, как вторая
волна методологий. Объектно-ориентированная разработка информационных систем стала еще одной «серебряной пулей» и, безусловно, оказала большое влияние на практику. Йордан утверждает, что
69
этот подход является более естественным, чем альтернативы, основанные на данных или процессах, и что подход объединяет процесс разработки информационных систем. Это также облегчает реальное повторное использование программного кода. Исследователи определяют и ряд других мотиваций и выгод для объектно-ориентированного
анализа, в том числе: способность решать более сложные проблемные
ситуации; улучшение отношений между аналитиками и пользователями, потому что он не ориентирован на компьютер, улучшение совместимости результатов, потому что он моделирует все аспекты проблемы одинаковым образом, и способность представлять факторы для изменения модели, в итоге приводящую к более устойчивой модели.
В некоторой степени, поэтому, он заменил одиночные акценты на
данных и процессах в разработке информационных систем.
Разрастающаяся или эволюционная разработка (часто включая
прототипирование) также является характерной чертой разработок
1990-х годов. Разрастающееся разработки похожи на надстраивание и
совершенствование, предыдущих версий, а не разработку новой системы каждый раз. Разрастающаяся разработка направлена на снижение продолжительности времени, которое требуется, чтобы разработать систему, и это решает проблему изменяющихся требований в результате обучения, происходящего в процессе разработки. Разрабатываемая система делится на ряд компонентов, которые могут быть
разработаны отдельно. Этот поэтапный подход является особенностью методологии DSDM. В настоящее время разработка приложений
из компонентов, происходящих из разных источников, приобрела популярность, как получающая программные компоненты с открытым
исходным кодом.
Некоторые методологии были разработаны для конкретных типов
применения. Такие методологии специального назначения включают
метод Welti для разработки ERP приложений; CommonKADS для
приложений управляемых знаниями; Process Innovation для приложений ре-инжиниринга бизнес-процессов, Renaissance, поддерживающую обратную инженерию существующих систем и WISDM для вебразработки.
70
Вышеизложенное может быть охарактеризовано, как период методологий из-за очевидного разрастания различных типов методологий
и их возрастающей зрелости. Работа IFIP WG 8.2 акцентировалась на
человеческих и организационных аспектах разработки информационных систем.
Многие пользователи методологий считают водопадную модель и
альтернативные методологии, описанные выше, неудовлетворительными. Большинство методологий предназначены для ситуаций, которые соответствуют определенному, или более часто, неопределенному «идеальному типу». Тем не менее, все ситуации отличаются друг
от друга и нет такого понятия, как «идеальный тип», хотя ситуации
отличаются в зависимости от, например, их сложности и структурированности, типа и скорости перемен в организации, числа задействованных пользователей и аналитиков и их навыков. Кроме того,
большинство пользователей методологий, как предполагается, следуют шаг за шагом, в нисходящем подходе к разработке информационных систем, где они выполняют ряд итераций, следуя к выполнению проекта. На самом деле, в любом проекте это встречается редко,
так как некоторые фазы могут быть опущены, другие выполняются в
другой последовательности, а третьи выполняются иначе, чем предполагалось авторами методологий. Точно так же, конкретные методы
и инструменты могут быть использованы по-разному или не использованы вовсе в различных обстоятельствах.
Для рассмотренных трудностей было предложен ряд ответных решений. Одно решение заключается в предложении ситуационного
подхода к разработке информационных систем (в отличие от директивного подхода), где представлена структура процесса разработки,
но этапы, фазы, инструменты, методы, и так далее, как ожидается,
будут использоваться или нет (или использоваться и адаптироваться),
в зависимости от ситуации. Эти характеристики, которые будут влиять на выбор конкретной комбинации способов, средств и методов
для конкретной ситуации, могли бы включать тип проекта, будь то
система операционного уровня (система обработки транзакций) или
информационная система менеджмента, размер проекта, важность
проекта, прогнозируемый срок осуществления проекта, характери71
стики проблемной области, имеющиеся навыки и так далее. Multiview
является таким ситуационным фреймворком.
Много было сделано попыток для сравнения и сопоставления этого разнообразия методологий. Некоторые исследователи сравнивают
методологии на основе философии (парадигмы, целей, рассматриваемой области ситуаций, целевого объекта разработки); применяемых
моделей и средств; широты охвата этапов разработки. Другие – на основе практики (основных принципов, баз и пользователей методологий,
участников разработки, содержания и формы представления методологии как продукта). Относительно количества существующих методологий, некоторые оценки предполагают, что во всем мире существовало
более 1000 брэндовых методологий, хотя можно довольно скептически
относиться к такому высокому числу, нет никаких сомнений в том, что
методологии разрастались, хотя многие из них были похожи и дифференцировались только в маркетинговых целях. Тем не менее, категоризация этого как период методологий не означает, что каждая организация использовала методологию разработки систем. В самом деле, некоторые из них не использовали методологию вовсе, но большинство, повидимому, использовало какую-то методологию собственной разработки или приспособленную методологию, основанную на или находящуюся под сильным влиянием продукта коммерческой методологии.
2.3.5. Период постметодологий
Текущая ситуация определяется как период постметодологий, в том
смысле, что мы сейчас воспринимаем методологии как развивающиеся
далее уже за пределами эры чистой методологии. Сейчас кажется, что
хотя некоторые организации все еще используют методологию некоторого вида, существует еще достаточно переоценок предположений выгоды методологий, даже негативной реакции против методологий, совместно с множеством и разнообразием не методологических подходов
для обоснования характеристики отражаемого периода.
Методологии часто рассматривались как панацея от проблем традиционных подходов разработки, и они часто выбирались и принимались по ошибочным причинам. Некоторые организации просто хо72
тели лучший механизм контроля проекта, другие лучший способ привлечения пользователей, в то время как другие хотели ввести некоторую строгость или дисциплину в процесс разработки. Для многих из
этих организаций принятие методологии не всегда срабатывало и
приносило всеобщий успех, на который рассчитывали их сторонники.
Несомненно, было весьма маловероятно, что методологии могли когда-нибудь достичь более высоких притязаний за счет поставщиков и
консультантов. Некоторые организации обнаруживали, что выбранная ими методология не является успешной или подходящей для них
и принимали другую. Для некоторых из них второй выбор был более
полезным, но другие обнаруживали, что принятая новая методология
также не является успешной. Это привело некоторых людей к отказу
от методологий в целом. Существующий опыт показывает, что это
является не единичной реакцией, и существует что-то, что может
быть определено как реакция против формального подхода методологий разработки информационных систем.
Это не означает, что методологии не были успешными. Это означает, что они не решали все проблемы, которые предполагалось, что
они решат. Многие организации используют методологии эффективно и успешно и утверждают, что, не являясь совершенными, они являются улучшением по сравнению с тем, как они делали свою работу
ранее, и что они не смогли бы управиться с текущей нагрузкой по
разработке систем без них.
Тем не менее, в эру постметодологий, существует много причин,
почему организации ставят под сомнение необходимость принятия
каких-либо методологий, таких как следующие. Производительность
– наиболее общей критикой методологий является то, что они не в
состоянии поставить предлагаемую ими выгоды производительности.
Сложность – методологии были подвергнуты критике за то, что они
слишком сложны. «Золочение лилии» – другие утверждают, что методологии разрабатывают любые требования до предельного качества,
часто сверх того, что обоснованно необходимо. Навыки – методологии требует значительных навыков в их использовании и применении. Инструменты – средства, которые предлагают методологии,
73
трудны в использовании, дороги и не генерируют достаточно преимуществ. Не зависят от условий – методологии не зависит от особенностей проекта. Одномерный подход – методологии обычно принимают только один подход к разработке проектов, который не всегда предназначен для решаемых вопросов или проблем. Негибкость –
методологии могут быть негибкими и могут не позволять производить изменения в требованиях при разработке (однако уже ведутся
исследования в области адаптивных методологий). Неверные или непрактичные предположения – большинство методологий делают ряд
упрощающих, вдобавок, потенциально необоснованных предположений, таких как стабильная внешняя и конкурентная среда. Смещение
цели – это относится к бездумному использованию методологии и акценту на вытекающие из этого процедуры в ущерб реальным потребностям разрабатываемого проекта. Это смещение цели, называемое
еще «фетиш метода», подавляет творческое мышление.
Проблемы встраивания понимания в методы – ряд исследователей утверждает, что некоторые методологии предполагают, что понимание может быть встроено в процесс метода. Они называют это
«методизмом» и считают, что это неуместно. Недостаточный акцент на социальных и контекстуальных вопросах – рост научно
обоснованных высоко функциональных методологий привел некоторых комментаторов к предположению, что мы сейчас страдаем от
чрезмерного внимания к узким техническим вопросам разработки
и, что не уделяется достаточного внимания социальным и организационным аспектам разработки систем. Трудности в принятии
методологии – некоторым организациям было трудно принять методологии на практике, отчасти из-за сопротивления пользователей
к изменениям. Отсутствие улучшений – последним в этом списке,
и, возможно, лакмусовым тестом является заключение некоторых,
что использование методологий не привело к более совершенным
системам по тем или иным причинам. Это, очевидно, трудно доказать, но тем не менее восприятием некоторых является то, что «мы
попробовали это, и это не помогло и это, возможно, активно препятствовало».
74
Таким образом, очевидно, что некоторые большие надежды 1980-х
и 1990-х годов, что методологии могли бы решить большинство проблем разработки информационных систем, не сбываются. Однако,
строго говоря, следует проводить различие в вышеуказанной критике
методологий между самой по себе неадекватной методологией и плохим применением и использованием методологии. Иногда поставщик
методологии будет утверждать, что методология не была неправильно применена организацией. Хотя это может быть верно, в некоторой
степени, это не является аргументом, который зависит во многом
от пользователей методологии. Они утверждают, что важным моментом является то, что они пережили разочарования в использовании
методологий.
Одна реакция на это состоит в отвержении подхода методологии в
целом. Обзор, проведенный в Великобритании, обнаружил, что 57%
выборки утверждали об использовании методологии для разработки
систем, но из них только 11% использовали коммерческие методологии разработки без изменений, в то время как 30% использовали
коммерческого методологии, адаптированные для собственного использования, и 59% использовали методологию, которую как они заявляли, являлась уникальной для них, то есть той, которая была разработана внутренне и не основана исключительно на коммерческой
методологии.
Существует разнообразие реакций на выявленные проблемы и
ограничения методологий. Рассмотрим некоторые из них. Начнем с
рассмотрения внешней разработки, но если выбор сделан в пользу
внутренней разработки, то пользователи могут требовать, что методология, которую они используют, нуждается в уточнении и улучшении (только потому, что они были в фазе методологии). С другой
стороны, пользователи могут предпочесть адаптировать методологию
в соответствии с конкретными потребностями каждого обстоятельства, следуя ситуационному подходу, или даже, более неформально и
рискованно, специальному подходу. В некоторых организациях скорость, а также гибкость стали девизом, и быстрые и динамичные подходы получили больше приверженцев, и укрепилась тенденция к
75
большему участию пользователей и клиентов. Наконец, предполагается, что мы находимся в более стабильной среде, чем в любое время
с начальных дней методологий разработки информационных систем
и основания IFIP TC8, и мы видим ее укрепление в ближайшем
будущем.
Внешняя разработка. Некоторые организации решили не вступать на путь любого более-менее крупного проекта по внутренней
разработке систем, а закупить все их требования в форме пакетов.
Это рассматривается как быстрый и относительно дешевый способ
внедрения систем для организаций, имеющих довольно стандартные
требования. Однако, довольно часто, может потребоваться, чтобы
стандартный пакет обладал некоторой степенью способности к модификации и интеграции, которые могут по-прежнему осуществляться внутренне в компании. Очевидно, что приобретение пакетов было
обычным явлением в течение некоторого времени в прошлом, но современная эпоха характеризуется существованием некоторых организаций, предпочитающих комплексные решения для программного пакета. Только системы, которые являются стратегическими, или для
которых подходящий пакет недоступен, могли бы рассматриваться
для внутренней разработки. Рынок пакетов становится все более
сложным, и становятся доступными все более и более высоко приспосабливаемые пакеты. Иногда компоненты с открытым исходным
кодом могут быть «упакованы» в форме приложения.
Системы планирование ресурсов предприятия (ERP) стали особенно популярны среди крупных корпораций, начиная с середины
90 -х годов. Ключевым для этих организаций является обеспечение
правильного компромисса между версией стандартного пакета и деятельностью предприятия, который может означать изменение некоторых элементов текущего способа работы бизнеса и одновременно
изменение и адаптацию пакета, в той степени, которая отражает то,
как предприятие хотело бы работать.
По мнению других, продолжающиеся проблемы разработки систем и негативной реакции на методологии привели к аутсорсингу
и/или на отдаление разработки систем от предприятия. Организация76
клиент больше не имеет никаких значительных забот о том, как разрабатываются системы. Они больше заинтересованы в конечных результатах и эффективности поставляемых систем. Это отличается от
покупки в пакетах или в решениях, потому что обычно в этом случае
руководство и ответственность за обеспечение и разработку соответствующих систем отдается поставщику. Компания-клиент должна
развивать навыки в выборе правильного поставщика, определении
требований в деталях и в составлении и заключении контрактов, а не
думать о методологиях разработки систем.
Продолжение доработки и улучшения. Одна из реакций на критику от пользователей методологий состоит в применении правильной
методологии авторами и поставщиками. Для некоторых она состоит в
постоянном поиске методологии. Методологии, вероятно, будут разрабатываться, время от времени и, что более вероятно, будут развиваться
существующие. Большинство методологий обладают некоторыми пробелами или, если не полными разрывами, в них существуют области,
которые рассматриваются методологиями гораздо менее тщательно,
чем другие. Например, диаграммы рич пикче (карты разума), когнитивное графическое отображение, нестандартное мышление, планирование
сценариев, рассуждения, основанные на случае, и анализ заинтересованных сторон представляют некоторые из методов, редко включаемых
в методологии, но мы видим веские причины для их включения. Ряд
исследователей показывают, как аналитики могут осуществлять выбор
между способами, а также потенциальную опасность их использования.
Точно так же, подверглись значительной проработке наборы инструментов за период с простых инструментов для рисования до всеобъемлющих наборов инструментов, часть из которых предназначена для
поддержки одной конкретной методологии и других для поддержки
разработки информационных систем в целом.
В частности, сейчас появляются методологии для разработки систем для Интернета. Приложения информационных систем в этой
среде, как утверждается, имеют некоторые особые характеристики,
которые делают применение традиционных методологий нецелесообразным. Ряд исследователей, например, определяют их как следую77
щие – сжатость разработки во времени, расплывчатость требований,
прототипирование, ориентация на варианты, параллельность разработки, фиксированная архитектура, согласованное качество, зависимость от «добрых людей», и потребность в структуре. Методология
WISDM также рассматривает веб-разработки. Некоторые из методологий, разработанные для веб-разработки, используют термин «динамичный», чтобы охарактеризовать необходимость в обеспечении гибкости и адаптивности в веб-разработке, которая отличает их от традиционных подходов (см. ниже).
Специальная и ситуационная разработка. Это может быть определено как возвращение ко времени существования преметодологий,
когда не существовало формализованных методологий. Подход, который принят, состоит в использовании чего бы ни было, что разработчики понимают и чувствуют будет работать. Он приводится в движение и
в значительной мере опирается на навыки и опыт разработчиков. Сторонники этого подхода, как реакции против обычных методологий, говорят о аметодологической и новой разработке информационных систем. Это, пожалуй, понятная реакция, но это приводит к риску повторения проблем, возникших до появления методологий.
Ситуационный подход разработки информационных систем рассматривается, как подход, обеспечивающий положительную реакцию, и как выбор хорошего баланса. Он представляет структуру для
помощи разработчикам, но средства и методы, которые предполагаются должны быть использованы, зависят от ситуации. Ситуации могут отличаться в зависимости от, например, типа проекта и его цели,
организации и ее окружения, пользователей и разработчиков и их соответствующих навыков. Тип проекта также может отличаться по
своему назначению, сложности, структурированности и степени важности, прогнозируемого срока реализации проекта, или его потенциального влияния. Ситуационный подход является ответной реакцией
на «одну методологию всех разработок», подходом, который принимают некоторые компании, и признанием, что различные характеристики требуют отличающихся подходов, и как это видно, такой подход приобретает возрастающее значение.
78
Динамичная разработка. Когда рассматривается динамичная или
быстрая разработка, выделяются требования и, как исследователи говорят о том, подход делает больше ударение на вовлечение пользователей и клиентов в совместный подход к разработке информационных систем. При этом он уделяет меньше внимания процессам и инструментам, работающему программному обеспечению с исчерпывающей документацией, сотрудничеству заказчиков в переговорах по
контрактам и на привнесение изменений, следуя плану. Работающее
программное обеспечение поставляется в более мелких частях, чем
традиционно, но в гораздо более короткий промежуток времени. Изменяющиеся требования принимаются как норма и даже приветствуется. Эти принципы более соответствуют современным потребностям
разработки информационных систем, чем принципы многих из методологий разработки систем «эры методологии», например, потребностям в реагировании на «скорость развития Интернета». Эти особенности присутствуют в экстремальном программировании (XP) и в
SCRUM, а также как и в таких подходах разработки информационных систем, как DSDM.
Консолидация, укрепление, усиление, объединение. В публикациях 1988, 1995 и 2002 г., в работах обсуждалось 9, 12 и 34 тем;
8, 11 и 37 методов; 7, 6 и 12 инструментов; а также 8, 15 и 32 методологий соответственно. Несмотря на все исследовательские усилия в 2006 году, эти цифры не увеличились, на самом деле имело
место снижение численности, так как некоторые методологии (и
связанные с ними методы и инструменты) выходят из употребления. Тем не менее, это не обязательно указывает на выход из употребления фреймворков и методологий для разработки информационных систем в целом, а, скорее, происходит процесс объединения.
В самом деле, мы видим некоторые методологии эпохи методологий используется эффективно и успешно, также как и гибкие и
условные подходы к разработке информационных систем. Это может также свидетельствовать о большей зрелости в целом области
информационных систем, и можно считать, что этот процесс объединения продолжается.
79
В этом разделе была предпринята попытка рассмотреть, хотя и
кратко, историю и движущие силы методологий разработки информационных систем. Был использован анализ для отражения и обсуждения текущего положения, определенного как постметодологический период. Это привело к определению четырех различных эпох
методологий. Наш современный период, пожалуй, лучше всего определяется как период переоценки методологий, приводящей к разнообразию реакций. Хотя считается, что маловероятно, что любой отдельный подход обеспечит решение всех проблем разработки информационных систем, мы действительно теперь видим перемену. Разнообразие методологий и рост количества подобных методологий было
заменено некоторым их объединением. Разработка информационных
систем вступила в фазу созревания большей стабильности.
2.4. Метод структурного анализа и дизайна систем SSADM
Методология SSADM (Structured System Analysis and Design Method) была разработана в Великобритании. Она применялась рядом
приложений в государственных органах, начиная с 1981 г., и ее использование стало обязательным в приложениях государственной
службы, начиная с 1983 г. SSADM также широко применяется другими организациями государственного и частного сектора. Она
больше всего подходит для крупномасштабных проектов, хотя существуют намерения ее адаптации и для небольших систем. SSADM –
это открытая система, находится в свободном доступе и может использоваться без приобретения лицензий и оплаты. Эта методология
имеет большое значение в Великобритании, ее версия 4 была выпущена в свет в 1990 г.
О ней говорят, что это управляемая данными методология из-за ее
истории и ее акценте на моделировании данных и базах данных, но в
своих более поздних версиях она стала более сбалансированной в
связи, например, с возросшей важностью учета роли пользователей.
SSADM версии 4 имеет семь этапов (пронумерованных от 0 до 6),
входящих в состав инфраструктуры образованной пятью модулями
80
(рис. 2.4), каждый из которых имеет собственный план, шкалу времени, контроль и процедуру мониторинга.
Методология точно определяет действия на каждом этапе и связанные с ними результаты. Эти средства способствуют применению
методов управления проектами. Она сконструирована таким образом,
что может взаимодействовать с программными продуктами, такими
как языки четвертого поколения. Она также совместима с некоторыми другими стандартными подходами, например, с методологией
управления проектами PRINCE. В частности, при использовании
данной методологии рекомендуется применение метода управления
проектами PRINCE.
Методология обеспечивает персонал разработки проекта очень подробными правилами и руководством для выполнения работы. Она
очень сильно структурирована. Другая причина ее успеха состоит в
обеспечиваемых ею стандартах (часто применяемых путем заполнения форм документов). Документация обеспечивает все аспекты проекта информационных систем. Во многом это истинный преемник
традиционного жизненного цикла разработки систем, но включающий новые методы и средства, созданные после 1970-х гг.
SSADM использует свою собственную терминологию. Даже такие
стандартные термины как «спецификация требований» и «схема потоков данных» имеют свои собственные специальные нюансы.
«Осуществимость» является опционной фазой, применяемой в зависимости от обстоятельств. Однако сравнительно с этапами традиционного жизненного цикла, имеющими подобные названия, SSADM
является более подробной, более точной методологией и использует
современные методы. Выходом SSADM являются документы, подтверждающие качество. Основные завершающие документы, в сущности, являются спецификациями технического дизайна для новой
компьютерной системы организации и включают в себя следующие
технические решения.
x Физический дизайн данных системы (спецификации компьютерных файлов или базы данных).
81
x Спецификации программного обеспечения, форматов входа/выхода и компьютерного диалога.
Модуль 1
Анализ
осуществимости
Модуль 2
Анализ требований
Этап 0
Осуществимость
Этап 1
Иследование текущей
среды
Этап 2
Варианты бинес
системы
SSADM
Модуль 3
Спецификация
требований
Модуль 4
Логическая
спецификация системы
Модуль 5
Физический дизайн
Этап 3
Определение
требований
Этап 4
Варианты технической
системы
Этап 5
Логический дизайн
Этап 6
Физический дизайн
Рис. 2.4. Отношение между модулями,
этапами и компонентами SSADM
Существуют также другие создаваемые промежуточные документы, из которых наиболее важными являются спецификации требований к будущей системе, предназначенные для утверждения менеджментом и пользователями.
Для создания вышеуказанных документов аналитик должен пройти через пять основных модулей SSADM, реализующих 6 этапов разработки, пронумерованных от 0 до 6, как показано на рис. 2.4. Модули представляют собой процедуры анализа и дизайна, которые со82
здают документы. Выход одного модуля является входом для следующего. Модули постепенно разрабатывают систему, пока не будут
созданы завершающие документы физического дизайна. Предполагается, что стадия планирования уже выполнена, и стадии, следующие
за дизайном, предположительно рассматриваются как присущие конкретной системе и, следовательно, не охватываются методологией.
Модули или этапы также подразделяются на пронумерованные шаги.
В целом методология предусматривает 33 шага, каждый из которых в
дальнейшем подразделяется на несколько задач. Каждая из этих задач
состоит из основных работ, подобных подготовке конкретных схем.
Ниже приводится более подробное описание модулей, этапов и задач.
Модуль 1 – Анализ осуществимости
Этап 0 – Осуществимость
010 Подготовка к исследованию осуществимости
020 Определение проблемы
030 Выбор опции осуществимости
040 Составление отчета осуществимости
Модуль 2 – Анализ требований
Этап 1 – Исследование текущей среды
110 Установление рамок анализа
120 Исследование и определение требований
130 Исследование текущей обработки
140 Исследование текущих данных
150 Установление логического представления текущего обслуживания
160 Компоновка результатов исследований
Этап 2 – Варианты бизнес системы
210 Определение опций бизнес системы
220 Выбор опций бизнес системы
Модуль 3 – Спецификация требований
Этап 3 – Определение требований
310 Определение требуемой обработки системы
320 Определение требуемой модели данных
330 Определение функций системы
83
340 Улучшение требуемой модели данных
350 Разработка спецификации макета
360 Разработка спецификации обработки
370 Контроль целей системы
380 Компоновка спецификаций требований
Модуль 4 –Логическая спецификация системы
Этап 4 – Варианты технической системы
410 Определение опций технической системы
420 Выбор опций технической системы
Этап 5 – Логический дизайн
510 Проектирование диалогов пользователей
520 Определение процессов обновления
530 Определение процессов запросов
540 Компоновка логического дизайна
Модуль 5 – Физический дизайн
Этап 6 – Физический дизайн
610 Подготовка к физическому дизайну
620 Создание физической модели данных
630 Создание схемы внедрения функциональных компонент
640 Оптимизация физической модели данных
650 Завершение функциональных спецификаций
660 Консолидация сопряжения процессов по данным
670 Компоновка физического дизайна
Этап 0 – осуществимость. Этот этап связан с обеспечением того,
что проект, который был предложен при планировании, является
осуществимым, т.е. что он технически возможен и выгоды от будущей информационной системы превысят расходы.
Этот этап состоит из четырех шагов: подготовка к изучению, которая определяет масштаб намерения проекта; идентификация проблемы, которая сравнивает требования с текущим состоянием; выбор варианта осуществления, который рассматривает альтернативы и выбирает одну; компоновка технико-экономического отчета.
На этом этапе используются такие методы исследования как проведение интервью, опроса и т. п., а также такие, как новейшие методы
84
графического представления потоков данных, составленных в результате анализа потоков документов. Как можно ожидать, на этапе осуществимости все моделирование выполняется в общих чертах, а не
слишком подробно. Эти подробности будут определяться на более
поздних этапах.
При рассмотрении недостатков текущей системы частично определяются требования к новой системе, устанавливающие, что будет
делать система и ограничения на систему.
Если проблема определена таким способом, то становится возможным рассмотреть различные альтернативы (методология допускает рассмотрение до пяти бизнес-вариантов и такое же количество
технических решений) и рекомендовать лучший вариант как с точки
зрения интересов бизнеса, так и с технической точки зрения. Вся эта
информация включается в технический отчет.
Этап 1 – исследование текущей среды. Второй модуль – анализ
требований – включает в себя два этапа: исследование текущих требований и вариантов бизнес-системы организации. Этот модуль устанавливает область для последующих этапов, потому что он способствует полному пониманию требований новой системы и основывает
направления оставшейся части проекта.
Первый из этих двух этапов повторяет многое из того, что было
выполнено на этапе анализа осуществимости системы, но более подробно. Например, на этапе осуществимости схемы потоков данных
могли не включить в себя многое из обработки, которое не связано с
главными задачами и не декомпозировано более чем на два уровня. В
дальнейшем конфликты и неопределенности модели объектов потребуют разрешения. Несомненно, в некоторых проектах этап осуществимости выполняется в очень общих чертах, поэтому задачи исследования текущей среды могут иметь намного меньше основы для их
решения.
Рассматриваются результаты изучения осуществимости, и подвергается переоценке намерение проекта. План в целом согласовывается
с менеджментом. Требования новой системы рассматриваются снова
в соответствии с исследованием методов текущей обработки и дан85
ных текущей системы, но более подробно, чем на этапе осуществимости. Существующая модель физического потока данных отображается на модель логического потока данных, и это помогает оценить
существующую функциональность, требуемую в новой системе.
Кроме того, могут составляться матрицы, которые, например, показывают отношения между процессами и объектами (т. е. какой процесс выбирает информацию из какого объекта). Создаются каталоги,
такие как каталог пользователей, который перечисляет деятельность,
проводимую на каждой рабочем месте, и каталог требований, который описывает функциональные и нефункциональные требования.
Составляется полное описание результатов этого этапа, которое рассматривается как подлежащее сдаче.
Этап 2 – опции бизнес системы. На этом этапе определяется и
согласовывается функциональность новой системы. Требования
пользователей, которые были установлены на этапе 1 и выбраны в
результате технико-экономического анализа, переходят к следующему этапу (используя обычные методы анализ затрат и выгод) и
эти требования определяются более подробно. Очерчивается ряд
опций бизнес системы, удовлетворяющих этому минимальному
набору требований пользователей, и часть из них представляются
менеджменту, для выбора одной из них (или может быть выбрана
гибридная опция, взятая из представленных). Для каждой из них
определяется в общих чертах стоимость, временной масштаб, технические ограничения, физическая организация, объемность, требования обучения, выгоды и влияние на организацию. Выбранная
опция подробно документируется и согласовывается как основа
спецификации системы, которая разрабатывается на следующем
шаге SSADM. Разрабатываются схемы потоков данных и модели
объектов, но спецификации этого этапа в значительной степени
имеют описательный характер.
Этап 3 – определение требований. Этот этап ведет к полной
спецификации требований и обеспечивает ясное направление для
последующих шагов дизайна. Подчеркивая важность этого этапа,
некоторые профессионалы применяют к нему метафору «машинное
86
отделение» SSADM. Здесь на смену исследованиям и анализу приходит детальное описание (которое может называться как технические требования, технические условия, спецификации, определение). Например, акцент здесь делается на проектирование требуемой системы, а не на функциональность текущей системы. Обсуждается и обновляется каталог требований, расширяется логическая
модель объектов, для которой выполняется нормализация. Расширяется также модель потоков данных. Она используется как средство связи c пользователями, с определением ролей пользователей в
новой системе, но она все еще является моделью объектов, на которой делается акцент на данном шаге и которая является основой для
логического дизайна новой системы. Для всех объектов и атрибутов
формируется документация.
Несмотря на то, что на этом этапе основное внимание уделяется
модели данных, определяются также компоненты каждой функции (в
терминах входа, выходов и событий или триггеров) Каждая функция
подробно документируется. При этом используется специальная
форма, в которой имеются места для записи наименования функции,
ее описания, обработки ошибок, процессов схемы потоков данных,
событий, описаний входа и выхода, Для описания структуры входа и
выхода применяются структурные диаграммы Джексона. Далее документация представляет также другие подробности, такие как отношения между ролями и функциями (при помощи матриц «роль пользователя/функция»).
Этот этап SSADM также включает в себя опциональную фазу макетирования. Методология предлагает создание макетов для демонстрации пользователям наиболее важных диалогов, структур меню,
что позволит проверить понимание аналитиком требований пользователей и их предпочтений по дизайну интерфейса. Также как и фаза
проверки спецификации, эта фаза может принести выгоды, такие,
например, как увеличение обязательства пользователя.
В течение этой фазы также конструируются истории жизни объектов
(или жизненные циклы объектов). Они документируют все события,
которые могут оказывать влияние на тип объекта и моделируют соот87
ветствующие бизнес-правила. События, оказывающие влияние на каждый объект, могут быть уже определены ранее путем создания матрицы
событие/объект. Кроме того матрицы полезны также для проверки, т. к.
объект обычно должен быть, по крайней мере, связан с одним событием создания и одним событием разрушения, и каждое событие должно
приводить к изменению, по крайней мере, одного объекта. В завершение этого этапа проводится проверка и подтверждение целей системы.
Осуществляется проверка функций на полноту определения и документирование полных спецификаций требований.
При разработке моделей жизненного цикла объектов, называемых
в SSADM историями жизни объектов, применяются условные графические обозначения, которые очень похожи на обозначения, принятые в методологии разработки систем Джексона. В SSADM эти схемы выглядят как иерархические структуры, они предназначены для
восприятия слева направо и в этом же порядке они последовательно
рассматривают различные состояния объекта.
Пример из сферы образования на рис. 2.5, а показывает изменение
во времени объекта «студент» следующим образом: кандидат, зарегистрированный и дипломированный (реально объект «студент» может
иметь и другой промежуточный статус).
На рис. 2.5, б представлено использование конструкции выбора,
когда символ «о» в изображении объектов «кандидат с офертой» и
«непригодный кандидат» указывает на альтернативные условия. Другая итеративная конструкция представлена на рис. 2.5, в. Здесь символ «*» указывает на событие, которое может повторяться (схема
предполагает вероятное повторяющееся приостановление и возобновление регистрации студента, который, возможно, регулярно опаздывает с оплатой за обучение).
На рис. 2.6 представлен пример истории жизни объекта. Первый
уровень содержит события, которые отмечают объект, включаемый в
систему, и те события, которые завершают пребывание объекта в системе.
88
Студент
Кандидат
Зарегистрированный
Дипломированный
а)
Кандидат
о
о
Непригодный кандидат
Кандидат с офертой
б)
*
Приостановление и
возобновление
регистрации
Повторно
зарегистрированный
студент
Приостановленный
студент
в)
Рис. 2.5. Конструкции истории жизни объекта SSADM
а) Последовательность; б) Выбор; в) Итерация
Здесь присутствует также итерационная конструкция, связанная с
тем, является ли студент принятым условно или нет, отражающая состояния приостановления и регистрации. Условие завершения пребывания объекта в системе определяется четырьмя состояниями: отчислившийся, дипломированный, не дипломированный или исключенный. Эти состояния являются взаимоисключающими (конструкция
выбора). Отметим, что в данной модели невозможно показать, что
«дипломированный» студент может происходить только из «зарегистрированных» и что «приостановленный» студент может закончить
только как «не дипломированный». Таким образом, часть информации теряется.
89
Студент
Заявление
Текущий *
студент
о
Условный
Бывший
студент
о
Допущенный
о
Отчислившийся
о
Не дипломированный
о
*
Зарегистрированный
Дипломированный
о
Исключенный
о
Приостановленный
Рис. 2.6. Модель истории жизни объекта SSADM
Этап 4 – опции технической системы. Этот и последующий этапы выполняются параллельно. На этапе опции технической системы
определяется среда, в которой будет действовать система. Среда
представляется в терминах конфигурации аппаратных и программных средств, стратегии разработки, влияния организации и функциональности системы.
Определение технических опций находится в зависимости от планируемой реализации системы, потому что существует большое количество альтернативных стратегий аппаратно-программного конфигурирования и внедрения. Для определения ограничений необходимо
выполнить анализ. Например, могут существовать исходные ограничения, включающие аппаратную платформу, минимальную и максимальную стоимость. Системные технические условия, включающие в
себя требования к производительности, безопасности, надежности и к
уровню обслуживания, требования которых должны быть выполне90
ны, могут ограничить выбор. Опции технической системы должны
соответствовать всем этим ограничениям и выбранный вариант должен быть согласован с менеджментом.
Этап 5 – логический дизайн. Он состоит в формулировке того,
что требуется делать системе, а не в предписании выполняемых действий для процедур или программ. Последнее является областью завершающего шестого этапа, на котором выполняется физический дизайн. На этапе 5 определяются структуры диалога и меню, а также их
оформление для конкретных пользователей или ролей пользователей.
На этом этапе рекомендуется привлекать пользователей и использовать
макеты, разработанные на этапе 3. Более того, следуя жизненным циклам объектов, разработанным на этапе 3, определяются процессы обновления и действия наряду с обработкой запросов, включая последовательность обработки. Другими словами, на этом этапе определяются
более подробно применение и управление операциями для каждого события. Специфицируются подробно такие действия как правила проверки введенных данных. В результате выполнения этого этапа создаются все требования для дизайна физических решений.
Этап 6 – физический дизайн. На этом завершающем этапе логический дизайн отображается на физическую среду. Это отображение
документируется в схеме внедрения функциональных компонент. Эта
фаза обеспечивает руководящие принципы для физического внедрения. Они должны быть применены для большинства конфигураций
аппаратных и программных средств. Тем не менее, этот этап выполняется с учетом реальной конфигурации. На этой фазе работ основная
роль отводится инженерам, программистам и, в частности, дизайнерам баз данных, хотя существует также потребность, как в аналитиках, так и в пользователях для проверки того, что завершающий дизайн удовлетворяет потребностям пользователей.
Логическая модель данных конвертируется в модель соответствующую используемой системой управления базами данных. Отображение базы данных является ключевым аспектом завершающего
внедрения и включает в себя не только определение способа представления отношений в базе данных, но и оперирование ключами и
91
методами доступа. Здесь многое зависит от определения производительности для достижения эффективного доступа к базе данных, а
также от фактической конфигурации программных и аппаратных
средств (включая систему управления базами данных).
Схема внедрения функциональных компонент перечисляет компоненты каждой логической функции и их отображение на физические
компоненты создаваемой системы. Методология SSADM достаточно
хорошо определяет принципы схемы внедрения функциональных
компонент, хотя форма этой схемы выражена не совсем определенно.
По-видимому, эту неопределенность в методологии надо рассматривать как представление возможности выбора в зависимости от требований конкретной организации. Модель оптимизируется в соответствии с техническими требованиями к памяти и временной синхронизации. Начиная с этого этапа, становится возможным выполнить дизайн и разработку программ необходимых для обеспечения требуемой функциональности. На этой точке разработки действие методологии SSADM завершается и начинается подробное проектирование
и тестирование.
Строго очерченная структура SSADM делает ее хорошо доступной
для усвоения. Многие университеты Великобритании используют эту
методологию для глубокого изучения информационных систем. При
этом они для сравнения также кратко рассматривают другие методологии. Три основные метода SSADM – модель объектов, схемы потоков данных и истории жизни объектов являются общими для многих
методологий, и они обеспечивают проведение подробного анализа
целевой системы. Одновременно со строго очерченными задачами и
руководством, включающим методы, методологии определяют предполагаемый выход, создаваемый на этапах, и дают руководящие
принципы для управления временем и ресурсами.
Предполагается, что SSADM должна применяться совместно с компьютерными средствами, и в настоящее время существует множество
средств, разработанных специально для пользователей этой методологии, также как и множество средств, разработанных для других методологий. Существует, например, ряд средств CASE, использующих сло92
вари данных и системные репозитории, помогающие осуществлять
анализ и дизайн, генерацию кодов на основе моделей SSADM, а также
вычерчивание моделей (схем сущность-связь, историй жизни объектов,
и схем потоков данных). Все они могут оказать существенную поддержку процесса разработки информационных систем.
Сторонники методологии также рекомендуют осуществлять анализ обеспечения качества, основанный на структурном сквозном контроле. Этот анализ осуществляется путем проведения заседаний, на
которых рассматривается конечные продукты различных фаз методологии, например, модели объектов, схемы потоков данных и истории
жизни объектов. Обычно конечный продукт представляется авторами
и рассматривается персоналом соответствующих групп проекта (помогая установлению хорошей связи между группами проекта и обеспечивая общий эталоны работы), группами специалистов обеспечения качества или группами пользователей. Цель этих заседаний состоит в определении ошибок в продукте. Решения обычно принимаются вне этих заседаний. Поощряется также осуществление обратной
связи по результатам функционирования внедренной системы, которая в данном случае рассматривается как аудит решений, принятых
при разработке системы.
Успешное внедрение методологии придает больше уверенности в
уровне квалификации имеющегося основного персонала (несмотря на
применение широко известных технических приемов и средств, а
также методов работы рабочих групп совместно со сквозным контролем), а также поддерживает качественное обучение и участие. Аналитики, прошедшие обучение традиционному подходу, признают многие из особенностей SSADM, и, в частности, акцент его на введенных
им образцах документации, ясные и подробные руководящие принципы и основательное обеспечение качества.
2.5. Информационная инженерия IE
Истоки этой методологии относят к концу 1970-х гг. Разработки
были начаты и проводились в Австралии и Великобритании. С тех
93
ранних пор существует ряд идейно очень похожих продуктов этой
методологии, которые многие ошибочно считают версиями, полученными в результате развития одного и того же продукта.
IE претендует на роль всеобъемлющей методологии, охватывающей все аспекты жизненного цикла. Она представляется как инфраструктура, в которой используются множество методов для разработки качественной информационной системы наиболее эффективным
способом. Утверждается, что эта инфраструктура является относительно статичной и включает основополагающие идеи, которые
должны быть выполнены для разработки хорошей информационной
системы. Методы, которые в настоящее время используются в IE, не
являются частью этих основ, а рассматриваются как наилучшие из
доступных сегодня методов для реализации этих идей. Она не представляет собой только набор идей, а признана как проверенный и
практичный подход. Также говорят, что она применима для широкого
спектра отраслей и сред. Инфраструктура также включает механизм
управления проектами, который отражает IE-философию «практичности» и «применяемости».
Существует ряд философских убеждений, обосновывающих IE.
Одно из начальных убеждений состоит в том, что данные составляют
сердцевину информационной системы и что данные, или, скорее, типы данных значительно более стабильны, чем процессы или процедуры, которые действуют в соответствии с данными. Таким образом,
методология, которая успешно определяет лежащую в основе природу и структуру данных организации, имеет прочный фундамент, на
котором строится информационная система. Методологии, которые
основываются только на процессах, склонны к неудаче из-за постоянно изменяющейся природы этой основы с изменением требований.
Это является классическим аргументом мышления школы моделирования данных. Однако IE ясно признает, что процессы также должны
рассматриваться подробно в разработке информационной системы, и
соответствующим образом балансирует моделированием данных и
моделированием процессов.
94
Следующим аспектом философии IE является убеждение, что
наиболее подходящий способ коммуникации внутри методологии состоит в использовании схем. Схемы очень притягательны для конечных пользователей и его менеджмента и, как известно, дают возможность им понимать, участвовать и даже создавать для себя релевантные IE схемы. Это помогает обеспечить учет и выполнение их требований. Схемы рассматриваются как достаточно точное средство для
фиксирования и представления всей необходимой информации.
Каждый IE-метод ориентирован на построение схемы, и схемы составляют результат каждого основного этапа методологии. Одним из
ключевых элементов IE является применение стандартных схем, которые первоначально определяются на высоком уровне представления и по мере выполнения проекта постепенно развертываются, становятся все более и более конкретными и подробными до тех пор,
пока они, в конечном счете, не составят потенциально выполнимое
приложение. В течение всего процесса разработки применяются
стандартные обозначения. Например, прямоугольники представляют
данные, прямоугольники с округленными углами представляют деятельность, применяются также условные обозначения, использующие
цвет, например, красный – для данных, а голубой – для деятельности.
IE-модель состоит их трех компонентов – данных, деятельности и
матрицы взаимодействия данных и деятельности (рис. 2.7). Взаимодействие может быть определено при помощи матрицы, указывающей на высоком уровне, какая предметная область используется в какой функции. На более низком уровне можно показать, какой тип
объекта данных используется каким процессом.
Автоматизированная поддержка, т. е. использование соответствующего средства CASE, определяется как основное требование IE методологии. Теоретически IE методология может быть применена и
для разработки, выполняемой вручную. Однако сложность организации и потребность в быстрой разработке системы означает, что на
практике поддержка разработки средствами CASE является абсолютно необходимой.
95
Данные
Деятельность
Взаимодействие
Х
Рис. 2.7. Данные, деятельность и взаимодействие
IE является нисходящей методологией и начинается с обзора
предприятия в целом, выполняемого высшим руководством. В этом
случае отдельные будущие подсистемы становятся потенциально связанными и согласованными, а не рассматриваются как индивидуальные проекты, что делает возможным применение общего стратегического подхода. По мере выполнения шагов методологии порождаются все большие и большие подробности будущей системы, относительно которых принимаются решения. Вначале для анализа выбираются области бизнеса, которые, как было уже сказано, основываются на едином плане организации. На дальнейших шагах внимание
аналитика концентрируется на подмножествах выбранных областей
для более детализированного дизайна и изготовления. Этот подход
для управления сложностью требований информационной системы,
называемый «разделяй и властвуй», показан на рис. 2.8. По мере выполнения методологии с каждым ее шагом, имеющим различные це96
ли, внимание разработчиков изменяется, при этом общие цели остаются совместимыми. Продвижение проекта контролируется измерением, достигнуты ли цели на каждом из этапов, а не количеством
сгенерированных подробностей будущей системы.
План
Выбранное
подмножество
Анализ
Дизайн
Изготовление
Рис. 2.8. Подход IE «разделяй и властвуй»
Методология разделена на четыре уровня, или слоя (рис. 2.9).
x Планирование информационной стратегии. Цель этого
уровня состоит в конструировании информационной архитектуры и
стратегий, которые поддерживает стратегии и потребности организации в целом. Это проводится на уровне предприятия. Одну часть
этого планирования составляет идентификация релевантных бизнес
областей.
x Анализ бизнес области. Здесь цель состоит в осмыслении отдельных бизнес областей и определение их требований к системе.
x Планирование системы и дизайн. Целью этого уровня является
установление желательных для пользователя свойств системы и того,
что они являются достижимыми при использовании технологий.
x Изготовление и переход. Цель состоит в построении и внедрении системы в соответствии с требованиями трех вышерассмотренных
уровней. Первые два уровня являются независимыми от технологий, в
то время как третий и четвертый уровни являются зависимыми от
предлагаемой технической среды.
97
Планирование
информационной
стратегии
Анализ
бизнес области
Планирование
системы и дизайн
Изготовление
и переход
Данные
Деятельность
Рис. 2.9. Четыре уровня IE
1. Планирование информационной стратегии. Основное содержание этого уровня связано с корпоративными целями в целом. Это
могло бы не всегда составлять часть методологии IE, если бы это
обычно выполнялось корпоративным менеджментом или планировщиками. Однако корпоративные цели признаются как основная
начальная точка для методологии. Это подразумевает, что информационная система организации должна быть создана для помощи в
осуществлении требований плана корпорации и что информационные
системы являются стратегически важными для организации. Корпоративный, или бизнес-план должен указывать бизнес-цели и стратегии, очерчивать главные бизнес-функции и их задачи и определять
структуру организации. План должен быть выражен в количественных терминах, и устанавливать приоритеты среди целей.
Планирование информационной стратегии включает в себя анализ
обзора бизнес-целей организации, ее главных бизнес-функций и информационных потребностей. Результат этого анализа состоит в так
называемой «информационной архитектуре», которая составляет основу для последующей разработки и обеспечения совместимости и
98
слаженности между различными системами в организации. Результирующий план информационной стратегии документирует бизнестребования и устанавливает приоритеты, являющиеся целесообразными для разработки информационных систем. План санкционирует
использование этих требований, сформулированных на высоком
уровне, в дальнейшей разработке всего проекта. Во многих других
методологиях, как известно, эти потребности неведомы, даже если бы
они когда-либо определялись. План также обеспечивает способ
управляемых изменений для предположений, приоритетов и целей в
том случае, если бы это было необходимо. Кроме таких изменений
план информационной стратегии должен оставаться относительно
неизменным. Процесс планирования информационной стратегии
предполагает совместную работу старшего основного руководства,
менеджмента пользователей и персонала информационной системы.
Он состоит в выполнении следующих четырех задач.
x Анализ текущей ситуации. Анализ представляет собой обзор
организации и текущего положения, включая рассмотрение достоинств и недостатков текущих систем. Обзор включат анализ бизнесстратегии, анализ информационной системы организации, анализ
технической среды и определение предварительной информационной
архитектуры (данных предметной области: заказчики или продукция
и основные бизнес функции).
x Анализ требований руководителей. Здесь менеджеры получают возможность установить их цели, потребности и понимания. Эти
факторы включают в себя информационные потребности, приоритеты, ответственность и проблемы. Это также связано с определением
целей бизнеса и определение того, как может быть использована технология для оказания помощи в достижении цели и способа, при помощи которого технологии могли бы повлиять на них. Определяются
критические факторы успеха для организации в целом, и осуществляется их декомпозиция, распространяющаяся на отдельные части организации.
x Определение архитектуры. Представляет собой обзор области
в терминах информации (определение глобальных типов объектов и
99
декомпозиция функций внутри предметных областей, описанных в
предварительной информационной архитектуре в анализе текущей
ситуации, рассмотренной выше), анализ распределения (географические требования для функций и данных), определение архитектуры
бизнес систем (изложение идеальных систем, требуемых организацией), определение технической архитектуры (изложение требуемых
направлений технологий для поддержки систем, включая аппаратные,
программные и коммуникационные средства) и определение организации информационной системы (предложение для организации
функций информационных систем, поддерживающих стратегию).
x План информационной стратегии. Включает в себя определение бизнес-областей (деление архитектур на логические бизнесгруппировки, каждая из которых могла бы формировать самостоятельный проект анализа), подготовку бизнес оценок (стратегии для
достижения архитектур, включая планы изменений для перехода из
текущей ситуации к желаемым целям) и подготовку самого плана
информационной стратегии (выбранная стратегия, включая приоритеты для разработки и рабочие программы для высокоприоритетных
проектов).
2. Анализ бизнес-области. На этом уровне рассматриваются отдельно области бизнеса, определенные в плане информационной
стратегии, и проводится подробный анализ данных и функций. Рекомендуется максимальное привлечение конечных пользователей. В задачи анализа бизнес-области входит следующее.
x Анализ объектов и функций. Это является главной задачей этапа. Он включает в себя анализ типов объектов и отношений, анализ
процессов и зависимостей, конструирование графических представлений всего, указанного выше: моделей объектов (подобие модели
сущность-связь), схем иерархии функций и схем зависимости процессов (подобие схем потоков данных, но без хранимых данных), и
определение атрибутов и представлений информации.
x Анализ взаимодействия. Исследуются отношение и взаимодействие между данными и функциями, т. е. динамика бизнеса. На рис.
2.10 представлен пример матрицы взаимодействия «функция/тип
100
объекта». В этом примере бизнес-функция обработки заказа рассматривается в форме схемы модели сущность-связь, иерархической схемы функция/процесс и матрицы взаимодействий между ними. Матрица отображает взаимодействия, исходя из того, осуществляет ли
функция создание, выборку, обновление или удаление объектов.
Пример является, отчасти, упрощенным, но он показывает, что заказы
и строки заказов никогда не удаляются. Это может быть ошибкой или
может указывать на то, что требуется добавление функции архивирования заказов.
x Анализ текущей (действующей) системы. Моделируются существующие системы точно таким же образом, как это выполнялось
в задаче анализа объектов и функций, для последующего проведения
сравнения моделей в задаче «подтверждение» (рассматривается ниже), чтобы можно было выполнить плановый переход из одного состояния в другое. Эта фаза включает конструирование схем потоков
данных процедур и подготовку модели данных методом канонического синтеза. Канонический синтез модели данных – это метод для
объединения всех данных, выявленных в отдельных частях организации, где они могли быть отчетами, экранными формами, диаграммами и т. п., в связанную структуру, являющуюся моделью объектов.
Метод использует вычерчивание кружковых диаграмм (схем, состоящих из овалов и стрелок) и синтез всех данных в модель объектов.
Кружковая диаграмма представляет собой граф направленных связей
между типами элементов данных (атрибутов) (рис. 2.11). Двойной эллипс представляет ключ, стрелка представляет зависимость один-кодному, двойная стрелка представляет зависимость один-ко-многим.
В этом случае ключ полностью определяет (или идентифицирует)
атрибуты, следовательно, данные являются нормализованными. Для
каждого отдельного представления пользователя данных создается
отдельная кружковая диаграмма. На рис. 2.12 представлен пример
трех представлений пользователей университетской среды. Представление 1 могло бы быть представлением секретаря, представление
2 могло бы быть представлением регистратора и представление 3 –
представлением менеджера. Процесс канонического синтеза объеди101
няет отдельные представления в единую модель данных. Каждое
представление является нормализованным и объединяется с другим,
любое дублирование в графе устраняется. На рис. 2.13 изображен результат соединения представления 1 и 2. Результат синтеза всех трех
представлений представлен на рис. 2.14
Данные
Деятельность
Схема сущность-связь
Схема иерархии функций
Обработка заказа
Заказчик
Заказ
Прием заказа
Подтверждение заказа
Строка заказа
Выполнение заказа
Поставка
Товар
Подтверждение заказчика
Запасы
Функция
Тип
объекта
Заказчик
ПодПрием тверждениее
заказа
R
Выполнение Поставка
R
CEUD
R
Заказ
C
RU
R
RU
Строка
C
RU
R
RU
RU
U
Товар
Подтвер- Запасы
ждение
заказчика
R
R
C = Create
R = Read only
U = Update
D = Delete
CRUD
Рис. 2.10. Пример матрицы «функция/тип объекта»
Ключ
Атрибут 1
Атрибут 2
Атрибут 3
Рис. 2.11. Кружковая диаграмма
.
102
Студент
Имя
Студент
Имя
Дисциплина
Лектор
Адрес
Степень
Дисциплина
Рис. 2.12. Три пользовательских представления
x Подтверждение. Состоит в перекрестном контроле вышерассмотренных результатов в показателях полноты, правильности и
устойчивости. Предположения, касающиеся перемен бизнеса, также
исследуются для определения влияний, которые они могут оказать.
Студент
Имя
Адрес
Дисциплина
Степень
Рис. 2.13. Синтез представления 1 и представления 2
Студент
Имя
Дисциплина
Лектор
Адрес
Рис. 2.14. Синтез всех трех представлений
103
Степень
x Планирование для дизайна. Этот шаг включает в себя определение областей дизайна (которые идентифицируют те части модели,
которые должны разрабатываться), оценку последовательности внедрения/перехода и планирование объектов дизайна. При этом осуществляется также идентификация областей, в которых могли бы
быть использованы существующие объекты (модели и коды) или
компоненты многократного применения. Это может быть связано с
многократным использованием объектов, создаваемых внутри, или
объектов, приобретаемых извне.
Сейчас это является важной областью для IE, ставящей своей целью ускорение процесса разработки систем. В дополнение необходимо отметить, что области, включающие объекты, создаваемые только
для внутреннего применения, могут в будущем затребовать их для
повторного использования, поэтому их дизайн следует осуществлять
с учетом возможности многократного применения. Дизайн для многократного применения связан с дополнительными требованиями, такими как гибкость и простота применения. Эффективная идентификация объектов для многократного применения требует применения
соответствующего репозитория.
Выходом из анализа области бизнеса является описание бизнесобласти, которое содержит бизнес-функции, и каждая функция разбивается на составляющие ее процессы более низкого уровня и зависимости процессов. Для данных описываются типы объектов, отношения и атрибуты совместно с их свойствами и примерами использования. Уровень детализации здесь гораздо выше, чем при построении
архитектур на этапе планирования информационной стратегии. Эта
информация обеспечивает основы для широкой идентификации бизнес процессов, требующих компьютерной поддержки.
3. Планирование и дизайн системы. Этот уровень разделяется на
дизайн бизнес системы и технический дизайн. В некоторых версиях
IE они называются внешний дизайн и внутренний дизайн.
Дизайн бизнес-системы. Для каждой идентифицированной области дизайна используется собранные факты для дизайна системы,
выполняющей идентифицированные бизнес-требования. Дизайн рас104
пространяется до уровня, на котором затрагиваются технические
факторы, т. е. это является логическим дизайном. Уровень планирования и дизайн системы состоят из следующих шагов.
x Предварительный дизайн структуры данных. Для обеспечения интеграции и совместимости для всех систем бизнес-области
этот шаг выполняется на уровне бизнеса в целом, а не только для области дизайна. Это включает первую попытку конвертирования модели объектов в структуру выбранной системы управления базами
данных. Она включает в себя обзор использования модели данных (в
основном анализ способа использования данных функциями для создания количественного представления, иногда называемого объемным) и подготовку предварительной структуры данных.
x Дизайн структуры системы. Включает в себя отображение
бизнес-процессов в процедуры и во взаимодействия, определенные
использованием схем потоков данных. Эта фаза предусматривает
определение процедур и подготовку схем потоков данных.
x Дизайн процедур. Этот этап включает в себя разработку схем
навигации данных (анализ путей доступа, который исследует типы и
объемность доступа, требуемого для конкретных типов объектов),
подготовку потоков диалогов (то есть, различных иерархий управления взаимодействием пользователя) и вычерчивание диаграмм действий. Иерархически структурированные диалоги и меню могут быть
представлены диаграммами действий, но не иерархические меню
требуют альтернативного схемного представления. Для этих целей IE
использует диаграммы потока диалогов (иногда называемых схемами
структуры диалогов). Простой пример такой диаграммы показан на
рис. 2.15. Вкратце, горизонтальные линии представляют экраны, а
вертикальные линии – потенциальные переходы или перемещения
между экранами. Это зависит от выбора, принятого пользователем.
Горизонтальная линия в сочетании с короткими вертикальными на
концах представляет процедуру, которая может быть экраном или
меню. Горизонтальная линия без коротких линий на ее концах представляет шаг процедуры, т. е. часть процедуры. Вертикальная линия
между процедурами показывает передачу управления от одной про105
цедуры к процедуре или шагу, отмеченному острием стрелки. Если
незаостренный конец вертикальной линии имеет кольцо, это представляет передачу управления со связью, которая означает, что
управление может быть возвращено обратно совместно с удержанным контекстом. Пример, показанный на рис. 2.15, представляет
структуру меню системы для обработки заказов клиентов.
Меню заказа
Проверка заказа
Добавление строки заказа
Удаление строки заказа
Изменение строки заказа
Подтверждение заказа
Создание заказа
Удаление заказа
Рис. 2.15. Пример потока диалогов
Первая процедура – это основное меню заказа и пользователь может выбрать три опции – проверка заказа, создание заказа или удаление заказа. Процедура проверки заказа предусматривает ввод номера
заказа и опции передачи управления со связью – добавления строки
заказа, удаление строки заказа или изменение строки заказа. При возврате управления процедуре проверки заказа данные, определяющие
новые детали заказа для выбранного заказчика, удерживаются и могут быть использованы этой процедурой. Отметим, что процедуры
добавления строки заказа и изменение строки заказа имеют опции
передачи управления процедуре подтверждения, которая является
шагом некоторой другой процедуры. В средствах CASE, основанных
на IE-методологии, составитель схем потоков диалогов обычно связан с функцией дизайна экранных форм, которая обеспечивает возможности для дизайнера путем щелчка по горизонтальной линии по106
лучать изображение соответствующей экранной формы и при необходимости переходить с одной экранной формы на другую в прямом
и обратном направлении.
x Подтверждение. Опять, как и часть дизайна бизнес-системы,
рассматриваемый уровень включает в себя этап подтверждения полноты, правильности, удобства и простоты использования. Для анализа полноты применяются матрицы. Проверка правильности осуществляется в соответствии с вопросом «соответствует ли это IEправилам?» Проверка удобства и простоты использования обычно
проводится на основе комментариев пользователей на макет.
x Планирование для технического дизайна. Завершающая фаза этого этапа включает в себя определение области внедрения и подготовку плана технического дизайна.
В конце этого этапа создается спецификация бизнес-системы организации, которая определяет для каждого бизнес процесса информационные потоки и процедуры пользователей, а также объединенные и согласованные результаты анализа бизнес-областей для каждой
компьютерной процедуры, плюс модели диалогов, экранных форм,
отчетов и других интерфейсов пользователей. Определяется также
масштаб предложенных компьютерных систем совместно с оценкой
работ по программированию и ресурсов для последующего этапа.
Технический дизайн. Определенные выше аспекты компьютеризации бизнес систем рассматриваются на техническом уровне исходя
из условия, чтобы можно было осуществить планирование и расчет
издержек для завершающего изготовления и эксплуатации систем.
Задачи этой фазы технического дизайна.
x Дизайн данных, который включает подготовку матриц загрузки
данных, уточнение структуры базы данных, дизайн памяти для хранения данных и дизайн других файлов.
x Дизайн программного обеспечения, который включает определение программ, модулей, шаблонов многократного использования,
группы интегрирования, дизайн модулей/программ, и определение
условий тестирования.
107
x Дизайн перехода на новую систему, который включает дизайн
программного обеспечения и процедур для запараллеливания и переноса, планирование развертывания систем (фазы на которых системы
внедряется по частям в местах расположения предприятия) и определение требований к обучению пользователей.
x Дизайн эксплуатации, который включает дизайн процедур безопасности и ограничений, дизайн процедур эксплуатации и мониторинга производительности и дизайн программного обеспечения для
эксплуатации.
x Проверка дизайна, которая включает оценочные испытания,
(тестирование продукта с целью определения его производительности по сравнению с ранними версиями или аналогичными продуктами конкурентов) и оценку рабочих характеристик.
x Дизайн системных испытаний, который включает определение испытаний системы и приемо-сдаточные испытания.
x Планирование внедрения, которое включает обзор издержек и
подготовку плана внедрения.
Выходом этого этапа является техническая спецификация,
включая программную и аппаратную среду, ее использование, стандарты и соглашения, план и ресурсы для последующего изготовления
и перехода.
4. Изготовление и переход. Этот уровень включает этапы изготовления, перехода и производственной эксплуатации.
Изготовление – это создание каждой определенной компоненты
внедрения и состоит из следующих задач.
x Генерация системы включает изготовление вычислительного
окружения, подготовку процедур разработки, создание базы данных и
файлов, генерацию модулей, генерацию данных проверки модулей,
выполнение комплексных испытаний и генерацию документации.
x Проверка правильности системы, которая включает генерацию данных проверки системы, выполнение проверки системы, генерацию данных приемо-сдаточных испытаний, проведение приемо-
108
сдаточных испытаний и утверждения результата. Рекомендуется
применение средств поддержки испытаний.
Переход представляет собой контролируемое переключение с
существующих систем и процедур на новую систему и установку аппаратных средств. Основными выполняемыми при этом задачами являются следующие.
x Подготовка, включающая подготовку графика перехода, обучение пользователей и установку аппаратных средств.
x Внедрение нового программного обеспечения включает переход на новое программное обеспечение и выполнение экспериментальных прогонов.
x Окончательная приемка включает акт соответствия системы
условиям приемки и полный переход на новую систему.
x Развертывание, или внедрение в местах расположения организации.
x Разработка вариантов системы, которая состоит в идентификации требований, модификации анализа и дизайна и выполнении изготовления и перехода, в одиночных местах расположения предприятия, где имеются отклонения от общеустановленных норм.
Переход считается осуществленным полностью, когда система
действует в течение определенного периода в соответствии с оговоренной устойчивостью и нормами и анализ ее функционирования соответствует установленным требованиям.
Производственная эксплуатация – это непрерывная успешная
работа системы в течение ее жизненного периода. Задачами этого периода является обеспечение обслуживания пользователей в рабочем
состоянии и принятие мер при изменении бизнес требований.
x Оценка системы, которая включает измерение эксплуатационных характеристик, сравнение выгод и затрат, приемлемости для
пользователей и выполнения сравнения с целями дизайна.
x Настройка, которая включает мониторинг, настройку программного обеспечения и реорганизацию баз данных.
109
x Эксплуатация, которая включает исправление ошибок и модификацию системы по требованию.
Уровни, этапы и задачи IE, рассмотренные выше, описаны в
последовательности, которая могла бы навести на мысль, что нисходящая классическая модель «водопад» находится в действии. Это не
обязательно является верным, и многое из разработки после уровня
планирования информационной стратегии, и особенно после уровня
анализа бизнес-области, может быть выполнено параллельно. Для
поддержки параллельной разработки конструируется модель согласования. Она является сверхвысокоуровневой моделью данных и
процессов, определяющей и выделяющей зависимости и необходимые интерфейсы между системами и подсистемами. Это делает возможным разбиение комплексной деятельности на управляемые компоненты, которые могут разрабатываться независимо. IE также заявляет о своей способности в поддержке множества путей через уровни разработки. Например, реверсивная инженерия начинает с нижней части инфраструктуры, т. е. с существующей реализации и выводит бизнес-правила из этой системы. Это может быть полезным,
когда возникает необходимость включения в рамки IE существующих систем, переставших удовлетворять изменившимся потребностям применений, но всё ещё находящихся в эксплуатации из-за
трудностей их замены, т. к. при проектировании в них не были заложены возможности перенастройки. IE может обеспечить реверсивная инженерию, которая представляет собой комбинацию прямого и обратного путей сквозь ее инфраструктуру. Разработчик может
«откатить» существующее приложение обратно до необходимой
точки и затем, после определения правил дизайна, объединить их с
некоторыми новыми требованиями и далее осуществить прямую
инженерию до уровня внедрения.
Как было упомянуто выше, IE во всевозрастающей степени зависит от средств CASE, и способность этой методологии к обратной
инженерии и ре-инженерии склоняет в пользу создания на ее основе
интегрированных средств CASE с совершенным репозиторием.
110
2.6. Методология MERISE
Merise является наиболее широко используемой методологией для
разработки информационных систем во Франции. Она применяется
как в государственном, так и в частном секторе. Ее влияние распространяется за пределы Франции и сейчас она применяется в Испании,
Швейцарии и Северной Америке. Merise может стать очень влиятельной в любых будущих европейских стандартах. Подход этой методологии применим для приложений обработки данных, использующих
базы данных, а также среду реального времени и пакетной обработки.
Особенность подхода методологии заключается в ее трех циклах:
цикле решений, жизненном цикле и цикле абстракций, которые распространяются на элементы данных и процессов с одинаковым акцентом.
Merise допускает участие пользователей и старшего менеджмента, также как и профессионалов по обработке данных, в ее цикле решений.
Существует ряд программных средств для использования с Merise.
Проект, который в результате привел к этой методологии, был
начат в 1977 г. французским Министерством промышленности и
включал исследовательские группы, консультативные и конструкторские фирмы, а также ученых. С тех пор Merise превратилась в весьма
основательную и всестороннюю методологию.
Основу подхода Merise составляют ее три цикла: цикл решений, который связан с разнообразными механизмами принятия решений, жизненный цикл, отражающий хронологический процесс проекта Merise от
начала до окончания и цикл абстракций, который описывает разнообразные модели для процессов и данных в каждом из трех этапов.
1. Цикл решений. Иногда его называют циклом утверждения. Он
состоит из всех механизмов решений, включая механизмы выбора
опций, в течении разработки информационной системы. Принятие
решений представляет собой совместный процесс старшего менеджмента, пользователей и разработчиков системы. Принимаемые решения включают:
x технические альтернативы, касающиеся аппаратных и программных средств;
111
x альтернативы обработки, такой как обработка реального времени или пакетная обработка;
x альтернативы, ориентированные на пользователей, связанные с
интерфейсом пользователя;
x решения идентификации в отношении основных действующих
лиц информационной системы и организации;
x финансовые решения, связанные со стоимостью и выгодами;
x решения управления, касающиеся функциональности информационной системы.
Merise идентифицирует каждую точку принятия решений в течение разработки информационной системы. Представляется важным
знать, кто принимает решение, в частности, тех, кто связан с проверкой различных моделей, используемых методом, и с решениями,
определяющими, когда завершать один этап и начинать следующий. Авторы Merise предлагают, что процесс принятия решений
должен выполняться в соответствии со схемой, представленной на
рис. 2.16.
Группы пользователей и разработчики системы совместно обсуждают различные опции (1). Ответственность за создание отчета, отражающего эти обсуждения, возлагается на группу пользователей (2).
Это затем обсуждается на совместном заседании (3) старшего менеджмента, пользователей и разработчиков приложений и решение
принимается в этой точке.
Такая структура процесса принятия решений обеспечивает достижение компромисса в случае конфликтующих представлений. Все
будет зависеть от норм, принятых в конкретной организации, тем не
менее, в самом процессе принятия решений присутствует внушительный элемент в лице пользователя и это влияет на одобрение окончательной системы, с точки зрения эксплуатационных и технических
критериев, а также удобства и простоты использования.
Таким образом, в Merise существуют возможности для оказания
влияния пользователем и участия в разработке, однако это не разъясняется подробно, т.к. зависит в большой степени от норм организации.
112
Члены более высокого
уровня иерархии в
организации
3
1
Члены группы
пользователей
2
1
2
3
Члены группы реализации
Совместная работа
Создание отчета, предлагающего некоторое решение
Решение
Рис. 2.16. Схема процесса принятия решений на каждом шаге
2. Жизненный цикл представляет хронологическое движение информационной системы вперед от ее замысла через разработку до завершающего анализа и устарения. Merise вполне хорошо определяет
каждый из этих этапов. Основными фазами жизненного цикла являются следующие.
x Стратегическое планирование (на корпоративном уровне),
которое отображает цели организации на ее информационные потребности и разделяет организацию на «домены» для дальнейшего
анализа (закупки, производство, финансы и персонал). Для каждого
из них разрабатывается график приложений, отражающий стратегию
для трудовых ресурсов, программных и аппаратных продуктов и
внедрения методологии разработки системы. Анализ, который только
что был выполнен в рамках стратегического плана для одного домена, должен быть также проведен и для всех остальных и после этого
становится возможным лучшее и более связанное осознание отношений между доменами.
113
x Предварительное изучение (для интересуемых доменов). Описываются предложенные информационные системы, обсуждается их
вероятное влияние и детализируются связанные расходы и выгоды, которые должны быть совместимыми со стратегическим планом.
x Подробное изучение (для конкретного проекта). Рассматриваются только те аспекты, которые будут автоматизированы, включая подробные спецификации для функционального дизайна (спецификации
требований) и технического дизайна (техническая архитектура).
x Графики и другая документация для разработки, внедрения и
сопровождения (все три графика на уровне приложения).
Иногда последний этап разбивается на три раздельных шага:
разработка, внедрение и сопровождение. Это немного отличается от
традиционной разработки систем. На практике выполнение последнего этапа будет отличаться в зависимости от используемых методов и
средств, разрабатываемых с 1970-х гг.
В целом рассматриваемый цикл подобен традиционному жизненному циклу, например, в SSADM и в других методологиях, и по
этой причине не будет обсуждаться подробно в дальнейшем. Однако
необходимо обратить внимание, что в противоположность многим
альтернативным подходам Merise включает фазу стратегического
планирования, и в этом отношении она подобна Information Engineering. Целью этого этапа является осуществление связи между целями
бизнеса и потребностями информационной системы.
Тем не менее, подобно SSADM, в Merise акцент направлен на анализ
и дизайн базы данных и соответствующих транзакций. Ссылка на
SSADM является удачной, т. к. ближайшим эквивалентом Merise является SSADM, наиболее используемая в Великобритании методология,
которая широко применяется в государственной гражданской службе и
в других организациях государственного и частного сектора.
3. Цикл абстракций. Является ключевым в Merise. В противоположность многим другим альтернативным подходам, раздельное рассмотрение данных и процессов в Merise является равноценно полным
и принимается во внимание с самого начала разработки. Моделирование представления данных осуществляется в три этапа: концепту114
альное, логическое и физическое. Аналогичным образом представление процессов моделируется через эквивалентные три этапа: концептуальный, организационный и операционный. Каждый из этих шести
уровней абстракции в цикле абстракций является представлением
информационной системы, и они должны быть совместимыми.
Цикл абстракций является в значительной мере нисходящим подходом, который начинает со знаний проблемной области (концептуальный этап); для принятия решений, связанных с ресурсами и задачами, и заканчивает техническими средствами, на которых внедряется результат. Концептуальный этап рассматривает организацию в целом. Логический этап исследует вопросы, такие как кто должен делать и что, где, когда и как. Тогда как физический этап рассматривает
ресурсы и окружающие технические ограничения, которые будут составлять действующую систему. Merise, следовательно, является независимой от технологий до последних фаз.
Рассмотренная выше логика моделирования Merise, представлена
в табл. 2.1. На концептуальном уровне группа объектов, имеющих
дело с информационной системой, представляется полностью независимым способом от существующих или будущих технических
средств. На этом уровне необходимо выяснить существо деятельности организации и состояния проблемы. На логическом уровне необходимо сделать выбор (используя модели, разработанные на концептуальном уровне), связанный с обработкой в терминах организации и
с моделями базы данных для данных, которые будут составлять часть
автоматизированной системы. Физический уровень это уровень, на
котором должны быть приняты во внимание ограничения, связанные
с операционной системой, системой управления базами данных и
языками программирования.
Исходное общее представление системы осуществляется при помощи схемы потоков Merise и создание ее предшествует концептуальным моделям (как данных, так и обработки). Схемы потоков
Merise не следует путать с более традиционными схемами потоков
данных. Схемы потоков Merise освещают информационные потоки
между различными действующими субъектами в исследуемых доме115
нах, вместе со средой. Они служат в качестве основы для разработки
концептуальной модели данных и концептуальной модели обработки.
Таблица 2.1
Уровни данных и обработки Merise
Уровень
Касательство
Что ты хочешь
КОНЦЕПТУАЛЬНЫЙ
делать?
ЛОГИЧЕСКИЙ
Кто должен деИЛИ
лать и что, коОРГАНИЗАЦИОННЫЙ гда, где, как?
Данные
Концептуальная
модель данных
Обработка
Концептуальная
модель обработки
Логическая
модель данных
Логическая или
организационная
ФИЗИЧЕСКИЙ ИЛИ
ОПЕРАЦИОННЫЙ
Физическая
модель данных
Операционная
модель
обработки
Какими средствами?
Схемы потоков данных связаны с аспектом обработки. Действующие субъекты описываются при помощи эллипсов, стрелки представляют информационные потоки между ними. Таким образом, схема
потоков, описывающая записи учета, поставщиков и заказчиков могла бы иметь вид, как показано на рис. 2.17. Здесь выделенные действующие субъекты являются внешними по отношению к информационной системе. Эта схема дает направления для создания концептуальной модели данных (имеющей отношение к заказчикам, счетам
и поставщикам) и концептуальной модели обработки (касающейся
расчетам по счетам) для рассматриваемого примера.
На концептуальном уровне информационная система представляется независимо от ее организационных, физических и компьютерных средств, которые она могла бы использовать. Целью концептуального уровня является формирование ответа на вопрос «что?» и
понимание сущности проблемы. Правила, доказанные на концептуальном уровне, являются «правилами менеджмента», анализируемого домена.
Графическое представление концептуальной модели данных является моделью сущность-связь, разработанной Питером Ченом в 1976 г.
Сущность (или объект) представляется в Merise прямоугольником, а
116
связь (или отношение) обозначаются эллипсом (рис. 2.18). Merise имеет
ряд правил, которые позволяют осуществлять проверку модели.
Концептуальная модель обработки описывает деятельность организации. Предметом рассмотрения концептуальной модели обработки являются события, операции и их синхронизация, или согласование.
Заказчик
Расчет по счету
Счет
Учетная запись
Счет
Платеж по счету
Поставщик
Рис. 2.17. Схема потоков Merise
СЧЕТ
(0,n)
Оплачивает
(0,1) ЗАКАЗЧИК
(0,n)
(1,1)
Посылает
Подписывает
(1,1)
(0,n)
ПОСТАВЩИК
КОНТРАКТ
Рис. 2.18. Концептуальная модель данных
Многие другие подходы, включающие в себя концепции операций
и событий, не используют концепцию синхронизации операций. Эта
концепция рассматривает условие или условия (события), которые
117
должны произойти для запуска операции и правило или набор правил
определяющих необходимые условия для запуска операции. Например, расчетный лист должен быть выпущен системой, если текущей
датой является 28 число месяца. Концептуальная модель обработки,
соответствующая подготовке расчетного листа, могла бы включать в
себя синхронизацию (расчетный лист изготавливается 28-го числа
месяца) на событие начала нового дня (рис. 2.19).
Дата
DATE = 28 число месяца
Получение расчетного листа
OK
not OK
Утвержденный лист
Неутвержденный лист
А
А
Корректировка листа
Уточненный лист
В
А
А или В
Получение расчетного листа
Расчетные листы для
работников
Записи в учете
Рис. 2.19. Концептуальная модель обработки
118
Модель организационной обработки используется и для прояснения всех идей, описанных в концептуальной модели обработки. Это
является вопросом, на котором следует остановиться как выполняются внутри организации методы обработки, какие из них могли бы
выполняться вручную (где процедуры выполняются без компьютерных ресурсов), диалоговым автоматизированным методом (где процедуры выполняются компьютерами и персоналом) или автоматически (где процедуры выполняются без вмешательства человека). Модель организационной обработки используется для определения, кто
осуществляет обработку, когда и как она выполняется. Модель организационной обработки основывается на концептуальной модели обработки с некоторыми изменениями, такими как детализация аспекта
наименований отделов, где будет происходить обработка. Для этого
модель рис. 2.19 могла бы быть усовершенствована так, чтобы обработка была распределена между управлением кадрами (подписание чеков), компьютерным отделом (получение расчетных листов) и бухгалтерией (записи учета).
Логическая модель данных находится между концептуальной моделью данных и физической моделью данных. Она представляет мир
данных, описанных в концептуальной модели, но с учетом выбранной
системы управления базами данных. Другими словами, логическая модель данных трансформирует концептуальную модель в форму, которая подходит для компьютеризации. Merise также предлагает полное
описание процесса нормализации данных.
Одним из наиболее важных аспектов Merise являются подробные
правила для конвертирования одной модели в другую (также как и
правила для создания каждой модели, например, существует десять
правил проверки для концептуальной модели обработки). Таким образом, в ней представлены правила для отображения концептуальной модели данных в логическую модель данных в реляционной
нормальной форме Бойса-Кодда (BCNF), как это показано на
табл. 2.2, а также описаны подробно правила для специальных случаев, таких как бинарные и n-арные отношения. Представлены также
правила для отображения в другие модели данных и оптимизации
119
реляционных и других моделей данных с учетом объема и активности их использования.
Таблица 2.2
Правила отображения концептуальной модели данных
в нормализованную реляционную модель
Концептуальная
модель данных
Идентификатор объекта
Свойство идентификатора
Объект
Отношение не с
кардинальностью (1,1)
Отношение с
кардинальностью (1,1)
становится
становится
становится
Логическая модель
данных в BCNF
Ключом
Атрибутом
Отношением
становится
Отношением
Отображение
теряется
На физическом уровне идентифицируются все технические альтернативы, которые делают возможным определить компьютерные
потребности, и это определение представляет собой последний этап
перед разработкой программного обеспечения. Цель физического
уровня состоит в ответе на вопрос, «с какими средствами?» Правила,
которые освещают физический уровень, являются «техническими
правилами». Это, следовательно, учитывает физические ресурсы (систему управления базами данных, аппаратные компьютерные средства, поддерживающие средства и т. п.). Типично физическая модель
данных может быть представлена как последовательность определений на SQL, модель операционной обработки как текст на структурном английском языке совместно с запросами на SQL к базе данных. Схемное представление процессов базы данных и запросов может быть представлено в форме схем потоков данных и отображено
на схемы структур данных. Merise предусматривает соответствующие
правила отображения.
Другой важный аспект Merise состоит в том, что методология позволяет отразить среду, где изменения являются обычным делом, и
120
новые потребности и направления могут быть встроены в модель как
развитие информационной системы. Например, даются руководства
для модификации концептуальной модели данных и концептуальной
модели обработки с учетом новых правил менеджмента для данных и
обработки. Более того, в противоположность традиционной методологии баз данных, которая направлена на статические, ориентированные на данные аспекты информационных систем, Merise, как это
видно, включает основательный анализ событий, операций и синхронизацию, представляющие все динамические аспекты информационной системы.
Каждая из шести моделей цикла абстракций располагает графическим формализмом, возможно, за исключением физической модели данных, поэтому методология полностью отдает себя в распоряжение поддерживающим средствам. Все три уровня абстракций
поддерживаются многими средствами, как для данных, так и процессов, облегчая задачу вычерчивания моделей. Некоторые из
средств проверяют или частично проверяют каждую из моделей,
помогают генерировать требуемую документацию на каждом этапе,
и могут включать в себя генератор приложений, интерфейс языка
запроса и словаря данных, которые облегчают задачу разработки
информационной системы.
Существует ряд поддерживающих средств, оказывающих помощь
пользователям Merise. Эти средства варьируются. Некоторые из них
являются средствами дизайна (например, для разработки различных
концептуальных и логических моделей и схем), другие средствами
моделирования и макетирования (для альтернативного представления окончательной системы) и третьи средствами исполнения и
генерации кодов (для генерации будущего приложения). Многие из
покупателей методологии обращают такое же большое внимание на
уровень качества поддерживающих средств, как и на основы самой
методологии.
Одна из важных причин принятия на вооружение методологии
разработки информационных систем состоит в соблюдении ею общепринятых стандартов, и поддержке графическими средствами всех
121
шести моделей цикла абстракций. Существуют стандарты и средства,
поддерживающие стратегическое планирование, планирование проектов, спецификации требований, а также файл опций и документации
для каждого определенного объекта, отношения, атрибута события и
операции. Стратегический план, например, вероятно, должен содержать диагностику текущей ситуации, перспективу развития организации, описание концептуального решения (что мы хотим делать) и планы развития относительно организации и технических решений. Он
также включает (для принятого решения) описание и информацию о
его влиянии (включая преимущества, риски, и средства), также как и
причины, по которым были отклонены другие решения.
Полная спецификация обработки, выполняемой системой, должна,
вероятно, включать модель обработки организации с подробным описанием процессов и модель оперативной обработки с перечнем приложений, транзакций и цепочек пакетов, а также описание их компоновки в компьютерных программах. Полная спецификация данных
должна включать концептуальную, логическую и физическую модели
данных. Она также должна содержать исследование ограничений
(безопасность и стратегия управления), подробности о взаимодействии с существующими приложениями и функциями. Приложения,
вероятно, должны включать определения отношений (в зависимости
от выбранного окончательного подхода к базе данных), список состояний и экранов для каждого процесса, их последовательность и физическое описание записей отношений.
Конечно, существуют проблемы, связанные с применением любой методологии, и, в частности, проблемы, связанные с обучением
и мотивацией персонала в использовании методологии, но Merise
имеет ряд положительных сторон, которые привлекают специалистов, снижая остроту этих проблем. К таким достоинствам относятся
следующие.
x Методология была хорошо проверена и испытана в ряде проектов во Франции, а также в Европе и Северной Америке.
x В своем жизненном цикле методология охватывает как стратегический план, так и традиционный жизненный цикл от концепции и
122
предварительного исследования, через разработку, внедрение, сопровождение, спад и замещение.
x В своем трехуровневом цикле абстракций методология охватывает как элементы данных, так и процессов с равным акцентом.
x Методология является в некоторых своих частях директивной,
но она делает возможным участие конечных пользователей и старшего менеджмента так же, как и профессионалов по обработке данных в
своем цикле решений.
x Она пытается принять во внимание любые новые потребности и
направления, идентифицированные как при сравнении с текущей
действующей системой, так и когда разрабатывает проект информационной системы.
x В настоящее время существует множество доступных средств,
поддерживающих Merise.
Ключевые термины
Модель потоков данных
Постметодологии
Преметодологии
Разработка систем
Ранние методологии
Сопровождение системы
Традиционный жизненный цикл
разработки систем
Эксплуатация системы
Этап анализа системы
Этап дизайна системы
Анализ осуществимости
Анализ функционирования
внедренной системы
Внедрение системы
Водопадная модель
Замещение системы
Изготовление системы
Инициирование проекта
Контроль качества системы
Методология разработки систем
Модель объектов
Модель потоков диалогов
123
Контрольные вопросы
1. Что подразумевает термин «разработка систем»?
2. Какая степень автоматизации может применяться в создаваемых информационных системах?
3. Участие каких категорий специалистов может предполагаться в разработке информационных систем?
4. Какие аспекты информационных систем рассматривает процесс разработки информационных систем?
5. Что определяет целесообразность применения методологий при разработке информационных систем?
6. Назовите этапы традиционного жизненного цикла разработки систем.
7. Что подразумевает термин «методология разработки систем»?
8. К какому классу решений организации относится выбор методологии для внедрения?
9. Назовите стадии разработки информационной системы управления,
определяемые ГОСТ 34.601.
10 Назовите стадии разработки информационной системы управления,
определяемые ГОСТ Р ИСО МЭК 15288-2005.
11. Дайте сравнение требований к стадиям разработки информационных систем стандартов ГОСТ 34.601 и ГОСТ Р ИСО МЭК 15288-2005.
12. Назовите известные вам методологии разработки систем.
13. Назовите основные этапы разработки, предусмотренные методологией SSADM, и кратко опишите эту методологию.
14. Какой класс явлений реального мира позволяет отразить модель истории жизни объекта?
15. Какие виды моделей применяются для отражения функциональности и данных информационных систем?
16. Назовите ряд основополагающих философских убеждений, обосновывающих методологию IE.
17. Назовите четыре уровня методологии IE и задачи каждого уровня.
18. Опишите как осуществляется канонический синтез модели данных.
19. Опишите модель потока диалогов.
20. Назовите и опишите три цикла методологии Merise.
21. Опишите взаимосвязь между тремя циклами методологии Merise.
124
22. Опишите схему процесса принятия решений на каждом шаге цикла
решений Merise и назовите решения, принимаемые по этой схеме.
23. Назовите три уровня и шесть моделей цикла абстракций методологии Merise и опишите их свойства.
24. Опишите схему потоков Merise.
25. Опишите концептуальная модель данных и концептуальную модель
обработки методологии Merise.
26. Назовите четыре периода эволюции методологий разработки информационных систем.
Глава 3. АНАЛИЗ МЕТОДОЛОГИЙ
Область методологий информационных систем можно охарактеризовать как «малопроходимые джунгли» и маловероятно, что ситуация
в ней в скором будущем изменится к лучшему из-за непрерывного
развития информационных технологий, информационных систем и в
целом организаций. Уже в 1994 г. в мире насчитывалось более
1000 брендовых методологий и их количество продолжает быстро
увеличиваться. Многие из них, конечно, очень похожи и видоизменены только для маркетинговых целей. Другие были разработаны собственными силами компаний для внутреннего применения. Тем не
менее, можно твердо утверждать, что в настоящее время существует
большое, сбивающее с толку многообразие методологий.
В этой главе сделана попытка кратко рассмотреть разработки и обсудить различные положения для помощи в понимании методологий
разработки информационных систем. Представленная в ней трактовка, рассмотрение, толкование являются, как теоретическими и философскими, так и практическими.
3.1. Определение методологий
Термин «методология» еще не очень хорошо определен ни в литературе, ни на практике. Между прочим, существует также мало согласия
о том, что можно противопоставить термину «очень общий уровень»,
который используется неопределенно и очень интенсивно.
Такое свободное использование термина «методология», конечно,
не означает, что для него не существует определения, просто для него не существует универсально-согласованного определения. На общем уровне методология рассматривается как рекомендованная серия шагов и процедур, прослеживаемых на пути разработки информационной системы. В более кратком и узком изложении, она проясняет почти максимум того, о чем договорились люди. Конечно,
такое определение ставит намного больше вопросов, чем дает ответов. Например:
126
x В чем состоит отличие между методологией и методом?
x Включает ли в себя методология спецификацию методов и
средств, которые должны использоваться?
x Составляет ли набор методов и средств методологию?
x Должно ли использование методология приводить каждый раз
к одному и тому же результату?
Вопросы, которые возникают в данном случае, являются сколь
фундаментальными, сколь и многочисленными. К сожалению, рассматриваемая проблема еще не разрешена. Смысл этого термина регулярно обсуждается в контексте информационных систем, и для него до сих пор не существует универсального определения.
Одно из наиболее полезных определений методологии было дано
Британским обществом по вычислительной технике в 1983 г.: это
«рекомендованный набор философских подходов, фаз, процедур,
правил, методов, средств, документации, менеджмента и обучения
для разработчиков информационных систем». Используя это определение, можно предположить, что методология должна содержать ряд
компонент, которые определяют:
x как должен разбиваться на этапы проект;
x какие задачи должны выполняться на каждом из этапов;
x какой вход должен создаваться на этапах;
x когда и при каких обстоятельствах эти этапы должны выполняться;
x какие применяются ограничения;
x какой персонал должен быть привлечен;
x как осуществляется менеджмент и контроль проекта;
x какие поддерживающие средства могут быть использованы.
В дополнение к этому методология должна определять подробно вопросы обучения пользователей методологии.
Отдельно от вышеуказанного методология должна также специально рассматривать важные положения «философии», под которой
подразумеваются основополагающие теории и допущения, в которые
верят авторы методологии. Философия, используемая в основе мето127
дологии, определяет те, иногда неописанные аспекты и убеждения,
которые делают методологию эффективным подходом для разработки информационных систем в глазах ее авторов. Вероятно, определение методологии должно включать специальные ссылки на ее философию, т. к. это имеет решающее значение для понимания конкретной методологии. Методология разработки информационных систем
является, следовательно, намного больше, чем набор методов совместно с использованием программных средств.
На практике многие методологии, особенно коммерческие, являются продуктами, которые объединены в пакет и могут включать руководства, обучение и подготовку (включая видео), консультативную
поддержку, средства CASE, примерные документы, образцы для построения моделей и т. п.
Некоторые считают, что термин «методология» не является подходящим в контексте разработки систем и что термин «метод» полностью соответствует тому, что называют методологией. В то время
как сторонники обсуждаемого термина считают, что термин «методология» имеет определенные характеристики, которые не подразумеваются термином «метод», например, включение в его смысл философских положений. Таким образом, методология является более
широкой концепцией, чем метод.
Сторонники термина говорят, что методология это набор принципов метода, который в некоторой практической ситуации должен
быть редуцирован до метода, однозначно подходящего для этой конкретной ситуации. Они также утверждают, что разработка информационной системы должна рассматриваться как форма расследования
в контексте общей модели систематизированного расследования, которое состоит из трех компонентов: интеллектуальной основы, методологии и прикладной области, предполагающих дальнейшие иерархические составляющие.
Первый компонент «интеллектуальная основа» заключает в себе
идеи, которые мы используем, чтобы понять мир. Интеллектуальная
основа методологии характеризуется как философия, которая руководит расследованием и ограничивает его. Она состоит из онтологиче128
ских предположений (онтология – учение о бытии, его основах,
принципах, структуре и закономерностях), т. е., убеждений о фундаментальной природе физического и социального мира и его действии
и эпистемологических предположений (раздел философии, изучающий основания знания или теория познания), т. е. тории о методах
или основе знаний. Она также состоит из этических ценностей, которые должны быть приобщены к методологии, и могли бы служить как
руководство или ограничение для расследования.
Второй компонент «методология» – это реализация интеллектуальной основы идей в виде набора рекомендаций или руководств для исследований, которые нуждаются в конкретных методах или способах.
Третий компонент «прикладная область», т. е. некоторая часть реального мира, которая считается проблематичной и заслуживающей
исследования.
Возвращаясь немного назад, можно увидеть, что прикладная область – это разработка информационных систем вообще. Компонент
«методология» является эквивалентом набору фаз, процедур, правил,
методов, способов, которые обычно считают методологией в мире
информационных систем. Интеллектуальная основа – это компонент,
который часто пропускается или не выражается явно в методологиях.
В рассматриваемом определении методологии большая часть этих
интеллектуальных основ включена в то, что называется основополагающей философией.
3.2. Обоснование необходимости методологий
Методологии возникли и развиваются из-за существующей объективной потребности или необходимости их применения, поэтому
представляется важным понимать, что мы ожидаем от методологий,
т. е. обоснованность принятия их «на вооружение». Очевидно, что это
существенно варьируется для организаций и лиц. Можно определить
три категории основных причин: улучшение конечного продукта
(разрабатываемой системы), улучшение процесса разработки и стандартизация процесса разработки.
129
Улучшение конечного продукта. Методологии применяются изза существующего желания улучшения конечного продукта разработки. Это не следует путать с качеством процесса разработки, рассматриваемого ниже. Существуют трудности в оценке качества информационной систем, созданных в результате использования конкретной
методологии. Например, мы не знаем, к каким конкретным результатам приведет использование методологии. Точно такой же результат,
возможно, может быть получен при применении другой методологии
или вовсе без ее применения. Кроме того, обычно мы не располагаем
широкими возможностями в создании контроля, при помощи которого можно было бы сравнивать результаты.
Даже если бы существовали такие способы сравнения результата
использования различных методологий, то элементы, принятые для
оценки качества различными экспертами, существенно бы отличались от лица к лицу, т.к. внутри сообщества информационных систем
не существует общего соглашения по этому положению. Ниже приводятся некоторые характеристики информационных систем, которые
могли бы быть использованы для оценки их качества.
x Приемлемость. Считают ли пользователи систему удовлетворительной, и соответствует ли она их информационным потребностям.
Это включает в себя бизнес пользователей и менеджеров и их требования.
x Работоспособность. Является ли система работоспособной,
когда и где это требуется.
x Связанность. Существует ли взаимодействие между компонентами (подсистемами), благодаря которому обеспечивается общая интеграция информационных систем и соответствующих ручных и бизнес систем.
x Совместимость. Согласовываются ли система с другими системами и другими частями организации.
x Документация. Является ли документация достаточно хорошей
для обеспечения взаимопонимания между операторами, пользователями, разработчиками и менеджерами.
130
x Легкость в изучении. Является ли обучение для новых пользователей коротким и наглядным.
x Экономичность. Является система доходной и не выходит ли
она за пределы выделенных ресурсов и ограничений.
x Действенность. Выполняет и действует ли система наиболее
лучшим способом, соответствующим общим целям организации и ее
бизнеса.
x Производительность. Использует ли система выделенные ресурсы с наибольшей пользой.
x Быстрый темп разработки. Является ли время, требуемое для
разработки проекта, достаточно быстрым относительно его размера и
сложности.
x Гибкость. Является ли система легкой в модификации, добавлении и удалении компонент.
x Функциональность. Обеспечивает ли система потребности организации.
x Внедряемость. Является ли осуществимым переход со старой
на новую информационную систему в техническом, социальном, экономическом и организационном смыслах.
x Слабая зависимость. Является ли взаимодействие между подсистемами таким, что они могут быть модифицированы без влияния
на остальную часть информационной системы.
x Сопровождаемость. Требуются ли большие усилия для поддержки системы в рабочем состоянии и ее соответствия изменяющимся требованиям в течении жизненного цикла.
x Переносимость. Может ли система выполняться на другом
оборудовании или в других местах.
x Надежность. Минимизирована ли частота ошибок и являются
ли выходы непротиворечивыми и правильными.
x Робастность. Является ли информационная система устойчивой к отказам и отказоустойчивой.
x Безопасность. Является ли система робастной по отношению к
неправильному использованию.
131
x Простота. Минимизирована ли неоднозначность и сложность.
x Проверяемость. Может ли система быть проверена полностью
для минимизации эксплуатационных отказов и недовольства пользователя.
x Своевременность. Действует ли система успешно в нормальных, экстремальных и других условиях, предоставляя информацию,
когда это требуется.
x Обозримость. Является ли возможным для пользователей отследить, почему имело место определенное действие.
Максимизация всех этих и других подобных критериев является,
конечно, недостижимой, т. к. некоторые из них являются противоречивыми. В идеальном случае методология может быть настроена так,
что предпочтение могло быть дано тем критериям, которые особенно
важны в данной проблемной ситуации. Такая настройка или какое-то
рассмотрение настройки встречается в методологиях редко.
Улучшение процесса разработки. Улучшение процесса разработки связано с увеличением выгоды, получаемой от строгого контроля процесса разработки и идентификации выхода на каждом этапе.
Это приводит к улучшенному управлению и контролю проекта.
Обычно считают, что c использованием методологии производительность улучшается, т. е. систему можно построить быстрее, выделив
специфические ресурсы, или использовать меньше ресурсов для достижения тех же самых результатов. Также иногда утверждают, что
использование методологии снижает уровень требуемой квалификации для аналитиков, что улучшает процесс разработки за счет снижения расходов.
Некоторые считают, что проблемы разработки информационных
систем могли бы быть улучшены за счет применения стандартов качества, которые доказали пригодность в производстве и промышленных процессах, например, BS5750/ISO9001. Эти стандарты разработаны, скорее, для обеспечения качества процессов, чем конечного
продукта, и это иногда является причиной акцента на соответствие
стандарту, независимо от того, улучшает ли это качество информационной системы.
132
Другая обсуждаемая проблема состоит в том, что процесс разработки программных продуктов очень сильно отличается от традиционного процесса производства. Информационная система является,
скорее, единичным продуктом, чем продуктом массового тиражирования дизайна. Существуют работы, в которых для преодоления этих
трудностей делаются попытки использования стандартов в методах,
применимых к разработке программных систем. Хотя такие стандарты еще не оказали большого влияния ни в смысле широты их распространения, ни в смысле улучшения качества программных продуктов,
они все же помогают поднять вопросы и уровень обсуждения, касающегося качества в разработке информационных систем.
Стандартизация процесса разработки. Потребности, связанные с
этой категорией, имеют отношение к выгоде приобретения общего
подхода для всей организации. Это подразумевает, что в результате
можно получить больше интегрированных систем, что персонал может легко изменяться от проекта к проекту без необходимости переобучения и что может быть успешно создана основа общего опыта и
знаний. Вкратце, могут быть получены все обычные выгоды стандартизации, включая специфические выгоды облегчения сопровождения
систем.
Все вышерассмотренные причины были определены в той или
иной форме авторами или поставщиками методологий как выгоды
применения их индивидуального подхода. В противоположность
этому, обзор выгод, которые ожидают пользователи от методологии,
показывает, что наиболее важными факторами для них являются
улучшенная спецификация систем и более легкое сопровождение и
совершенствование.
Методологии редко рассматривают прямо улучшение задачи сопровождения, хотя поставщики часто заявляют это как непрямую выгоду, потому что при использовании методологии разработанные информационные системы потребуют меньше сопровождения.
133
3.3. Истоки методологий
При понимании любой методологии очень важным аспектом являются ее «истоки». Методологии могут быть подразделены на две
категории: разработанные исходя из практики и разработанные исходя из теории.
Методологии первой категории обычно эволюционировали вследствие использования в организации и затем были переработаны в
коммерческий продукт. Вторая категория методологий типично эволюционировала в лабораториях и исследовательских институтах,
обычно описывается в книгах и журналах, хотя может развиться до
уровня коммерческих продуктов.
3.3.1. Коммерческие методологии
Коммерческие методологии, возникшие в результате практики, являются наиболее широко известными, и некоторые привлекли к себе
сотни, если не тысячи, пользователей. Каждая из них имеет свою историю, однако наиболее типичное происхождение связано с тем, что
разработчики систем в организации обнаруживали, что используемые
ими некоторые индивидуальные способы были намного полезнее, чем
другие, и они затем сосредоточивались на улучшении использования и
результативности этих способов. Персонал, реализующий эту идею,
мог обнаружить, что организация, на которую они работают, не заинтересована в разработке этого способа. Иногда это приводило к уходу
разработчиков из компании и к основанию ими их собственной компании, иногда к переходу в существующую консультативную компанию, где возможности разработки способов и методов были выше.
На этом этапе развиваемая ими идея еще не являлась методологией, но
она уже применялась ее авторами в консультативной работе по разработке информационных систем, которая продавалась клиентам.
Большинство ранних методологий основывались на одном способе
или на наборе тесно связанных способов. Как правило, этими способами были или моделирование объектов, или моделирование потоков
данных, но обычно использовали оба вида моделирования. Только
134
позже для расширения масштаба намерений методологии авторы методологий начали применять другие методы, рекомендации и фазы,
или этапы разработки. Эти неформальные процедуры приобрели вид
ранних методологий. Время от времени разработка методологий могла проходить через периоды самоанализа, когда некоторые аспекты
дополняли методологию, а другие удались, и затем пересмотренная
методология могла быть проверена, посредством дальнейшего использования на практике.
Иногда консультанты, используя одну и ту же методологию компании, могли обнаружить, что они выполняют свою работу иначе,
чем их коллеги. Они имели свои собственные стили и любимые элементы, при этом предполагалось, что все они применяют одну и ту же
методологию. На этом этапе некоторые из таких консультативных
компаний осознали, что больше невозможно полагаться на плохо
определенный, недостаточно исследованный, часто конфликтующий
набор процедур и способов. Становилось понятно, что вместо продажи консультационных услуг методология сама должна быть использована в качестве продукта. В некой организации это произошло, когда было обнаружено, что ни один из работников компании не отвечал за методологию и ее содержание. Персонал компании мог добавлять то, что считал нужным. Основная причина такого состояния дел
заключалась в природе консультационного бизнеса. Работа консультанта оплачивалась на основе количества времени, затраченного ими
на проект клиента. При этом не существовало механизма для вычисления времени, затраченного консультантом на разработку методологии или способа, при помощи которого он выполнял этот проект. Таким образом, никто не нес ответственности за методологию, потому
что на этом этапе она еще не являлась тем, что может быть продано.
В итоге большинство организаций с потенциальным продуктом
методологии осмелились и инвестировали ресурсы (людей и время) в
разработку методологии как продукта. Это привело к некоторой
определенности: методология должна быть подробно описанной,
совместимой, всесторонней, пригодной для продажи, обновляемой по
необходимости, сопровождаемой, исследуемой и разрабатываемой,
135
развертываемой в обучающие пакеты, обеспечиваемой поддерживающими программными средствами.
Консультирующие компании, в конечном счете, инвестировали
свои методологии. Эти вложения привели к ряду последствий.
Заполнение разрывов. Было осознано, что большинство методологий разработки информационных систем имели в себе некоторые
разрывы или, если и не полные разрывы, то области, которые рассматривались значительно менее основательно, чем другие. Это
обычно являлось прямым результатом их истока разработки, который
типично влек за собой концентрацию на одном или небольшом наборе способов разработки. Эти разрывы нуждались в заполнении, потому что их клиенты считали, что методологии охватывают весь спектр
необходимой деятельности. Часто пользователи неожиданно для себя
обнаруживали, что это на самом деле не так. Например, методология,
основанная на способах моделирования объектов, могла быть очень
мощной для анализа и дизайна баз данных, но не настолько полной,
когда дело доходило до определения функций и дизайна приложений,
и могла не обеспечивать никакой поддержки для дизайна диалога.
Почти все методологии информационных систем прошли через процесс заполнения разрывов и совершенствования в направлении расширения ее всесторонности.
Расширение области действия. Другим процессом было расширение области действия, потому что существующие методологии не
рассматривали полный цикл разработки систем. Часто они не включали фазу внедрения, некоторые не включали дизайн, другие не рассматривали анализ, поэтому принимались решения расширения масштаба методологий.
Одним из наиболее важных аспектов расширения области действия было ее распространение в область стратегии и планирования.
Традиционный жизненный цикл разработки систем обычно начинался с этапа, называемого «выбор проекта» или «идентификация проблемы», который характеризовался идентификацией некоторой проблемы, требующей решения, некоторой области бизнеса, где компьютеризация была возможной альтернативой, или выбором некоторого
136
необходимого приложения. Процесс разработки рассматривался как
единичное, специальное решение идентифицированной проблемы (в
тот ранний период разработки информационных систем такой подход
мог еще считаться обоснованным, однако в настоящее время он уже
не может оставаться приемлемым). Организации имели много таких
«идентифицированных проблем», решаемых в такой единичной манере, и пришли к заключению, что хотя отдельная проблема, возможно, решена в некоторой области, существование разнообразия различных единичных систем в бизнесе не привело ни к гармонии, ни к
какому-нибудь общему улучшению бизнес-процессов.
Более того, было осознано, что эти отдельные проблемы были не
так «индивидуальны», и что почти все области бизнеса нуждаются во
взаимодействии и интеграции. В частности, требования тактического
и стратегического уровней управления нуждались в интеграции через
традиционные границы. Серия систем, разработанных как отдельные
решения, в разное время и без ссылок друг на друга явно не являлась
идеальной начальной точкой для такой интеграции, поэтому методологии были вынуждены исследовать себя в этой ситуации, если они
должны были обеспечить нечто большее, чем улучшенное применение единичных систем. Таким образом, для обеспечения возможности совместной работы создаваемых приложений информационных
систем некоторые методологии были расширены для охвата ими вопросов области стратегии информационных систем. Это в результате
привело к широкому признанию следующих положений.
x Информационные системы являются существенной частью организации, и они могут значительно способствовать успеху предприятия.
x Информация должна расцениваться организацией как важный
ресурс, также как и более традиционные ее ресурсы: земля, труд и
капитал.
x Было осознано, что такой ресурс не был бесплатным, как предполагалось ранее, и что он требовал контроля, координации и планирования. Более того, контроль и планирование информационного ресурса должны осуществляться в большей степени на высшем уровне
137
в организации для того, чтобы эти ресурсы действенно способствовали достижению предприятием своих целей. Таким образом, исходная
точка для эффективных методологий разработки информационных
систем сейчас выглядела как стратегический план для организации,
включающий спецификацию способа, которым информационные системы могли способствовать выполнению этого плана.
На практике обнаружилось, что почти все организации имели некоторого рода стратегический или корпоративный план, который
обычно не учитывал роль информационных систем. По этой причине
некоторые методологии включили разработку требуемого плана стратегии в область их действия. Это не только помогло обеспечить соответствие информационных систем требованиям высокого уровня организации, но также продвинуло функции информационной системы
вверх по иерархии важности в организации.
Получение конкурентных преимуществ. Другая причина исследования стратегии информационных систем на высоком уровне в организации состояла в развивающемся убеждении, что информационные системы могут не только сделать бизнес более легким и более
эффективным, но также изменить положение организации относительно ее бизнес конкурентов. Мысль, что информационные системы
могут способствовать изменению бизнеса и получению преимущества, стала широко распространенной, поэтому большинство коммерческих методологий включило в себя фазу стратегии и планирования.
Это не только обеспечивало согласованность между стратегиями
предприятия и его информационной системы, но и приводило к оказанию влияния выявленных новых возможностей информационных
систем на определение бизнес-стратегии предприятия.
Процесс расширения области действия и заполнения разрывов продолжился для большинства коммерческих методологий. После введения фаз и задач стратегического и бизнес планирования, следующие
разработки должны были интегрировать новые и развивающиеся способы и подходы, такие как диаграммы перехода состояний (или жизненные циклы объектов), включение поддерживающих средств в пакеты методологий и освоение объектно-ориентированных методов.
138
В то время как поставщики существующих методологий добивались заполнения разрывов и расширяли область действия их продуктов, другие организации открыли рынок новых продуктов методологий. Они являлись новыми потому, что пытались смешать вместе то,
что рассматривалось как сильные стороны многообразия существующих методологий, в частности, комбинацию способов моделирования объектов со способами моделирования потоков данных. Типичным примером этого является SSADM.
Этот процесс расширения области действия и заполнения разрывов происходил во многих методологиях, становившихся крайне
большими и часто громоздкими. При этом разработчики старались
реализовать в методологиях все возможности процесса разработки
для всех возможных применений, но, осуществляя это, они, возможно, потеряли их первоначальную специфическую сосредоточенность
и посеяли семена для некоторой растущей неудовлетворенности методологиями, которая будет рассмотрено ниже.
3.3.2. Академические методологии
Вторая основная категория методологий развилась из академических
и теоретических истоков. Эти методологии менее хорошо известны,
чем коммерческие и могут иметь относительно меньше пользователей,
хотя их влияние является часто значительно большим, чем их пользовательская база. Академические методологии обычно разрабатывались
лицами, которые развивали и популяризировали методологии посредством исследовательских действий и консультирования.
Эти методологии начинали жизнь как исследовательские проекты
в университетах или исследовательских институтах. Здесь исследователи придерживались больше теоретической точки зрения и были
меньше обеспокоены коммерческим рассмотрением, хотя часто испытывали недостаток в доступе к реальным ситуациям для проверки
и эксперимента. Доход от консультирования, определенно, также не
являлся препятствием. То, что интересовало академических исследователей, не выглядело как стандартные способы или подходы, основанные на звучащих теоретически концепциях. Это было явно сложной задачей, взятой на себя рядом лиц из множества различных обра139
зовательных дисциплин. Иногда создавалось ощущение, что требуемые методы уже существовали, и успешно использовались в других
дисциплинах и что они только нуждаются в небольшой адаптации,
чтобы стать полезными в области разработки информационных систем. Математики, психологи, лингвисты, социологи, инженеры и
другие обратили свое внимание на эту задачу. Это все, конечно, случилось не в одно и то же время и фактически не вовлекло большое
количество людей, но некоторые из подходов оказались интересными
и полезными.
В других областях, не связанных с информационными системами,
разработка способов и методов учеными стала очень влиятельной на
практике, в частности, в областях дизайна баз данных и разработки
программного обеспечения. Но в области методологий разработки
информационных систем, по крайней мере, в начале, ученые были
почти полностью игнорированы.
Причина этого начального медленного роста популярности является спорной. Некоторые утверждали, что методы, основанные на исследованиях, были недостаточно хороши, недостаточно практичны
или что они были не лучше, чем новые методы, разработанные практиками. Некоторые академические методологии ввели относительно
революционные изменения для того времени, которые не могли появиться на основе практического базиса. Так, ведущие ученые в то
время отмечали: «Очень малая часть академических методологий
применена для практических случаев реально ощутимого размера и
сложности». Признание «академических» методов на практике является низким и, в общем, коэффициент трансфера результатов исследований и «ноу-хау» от научных исследований в промышленность
является удивительно малым».
Некоторые искали пути преодоления этой проблемы, склоняя организации к применению их методов под контролем и руководством самих ученых на основе консультирования. Другие применяли экспериментальные исследования, которые включают проведение исследований и испытаний методологии в практических ситуациях совместно с
учеными, выполняющими двойную роль участника и исследователя.
140
По мере развития этого процесса методологии становились более
практическими, в настоящее время, очевидно, что академические методологии выполняют более важную роль. Время от времени некоторые элементы академических методологий применялись в коммерческих методологиях, в то время как другие делали попытку объединения технологий данных и процессов, а также моделирования объектов и потоков данных, взятых из коммерческих методологий, с академическими методологиями, такими как SSM, в более комплексный
подход, например, Multiview.
3.4. Применение методологий
У организации, размышляющей о применении или покупке методологии, возникает целый ряд вопросов, связанных с тем, что они получат, и гарантируется ли им в результате успешная информационная
система.
Что они получат? Рассматривая первый вопрос, можно уверенно
утверждать: они получат то, что может дать поставщик или автор методологии, и это значительно различается. Возможные вариации характеристик методологий показывают следующие примеры.
x Методология может колебаться от абсолютно роскошного продукта, детализирующего каждый шаг и каждую решаемую задачу до
неясного очертания основных принципов в короткой брошюре.
x Методология может охватывать широко отличающиеся области
процесса разработки от решения стратегических и организационных
проблем высокого уровня до подробностей реализации малых компьютерных систем.
x Методология может охватывать концептуальные положения или
процедуры физического дизайна или целый ряд промежуточных шагов.
x Методология может колебаться от продуктов, разработанных
для применения к проблемам в среде или промышленности определенного типа, до всеохватывающей методологии общего назначения.
x Методология может быть потенциально применимой любым
лицом, или только высоко подготовленными специалистами, или со141
зданной для пользователей, разрабатывающих свои собственные приложения.
x Методология может потребовать большое количество людей,
чтобы выполнить все предусмотренные в ней задачи, или она может
не предусматривать ни одной из задач.
x Методология может или может не включать средства CASE
Ясно, что при применении методологии необходимо знать, в чем
состоят потребности, и соответственно с ними осуществлять выбор
методологии. Некая организация, которая приобрела одну из методологий, в результате обнаружила, что она должна самостоятельно составить подробный указатель для определения требований к собственному персоналу разработчиков информационных систем. Оказывается то, что она приобрела, являлось обзором менеджмента без
каких-либо подробностей.
Некоторые методологии покупаются как продукт, другие становятся доступными посредством приобретения лицензии, третьи получают через консультационное обслуживание, некоторые поступают
как часть приобретаемого средства CASE или через комбинацию рассмотренные выше путей. Стоимость методологий варьируется значительно. Некоторые фактически бесплатны (например, Merise). Часто
начальное приобретение продукта методологии является наименьшей
частью инвестиций, к последующим вложениям относятся расходы
на обучение, дополнительные аппаратные и программные средства и
постоянное консультирование, которое в итоге может во много раз
превысить стоимость начальной покупки. Потенциальные организационные расходы применения методологии, если она применена как
стандарт компании во всех ее отделениях, становятся огромными.
Эти организационные расходы не включают в себя цену покупки, это
расходы внедрения методологии в культуру организации, альтернативные затраты, стоимость обучения пользователей и менеджеров и
т. п. Расходы могут быть еще большими в связи с заменой применяемой ранее методологии. Если некоторая методология применялась
ранее, то переход на новую приводит к необходимости преодоления
культуры разработки, существовавшей ранее в организации.
142
Эти расходы обычно серьезно недооценивают при определении
расходов на методологии. Приведенный анализ расходов показывают,
что ни отдел ИТ ни отдел разработки систем, не должны непосредственно принимать решения, касающиеся применения определенной
методологии. Но на практике так сложилось, что в большинстве случаев решение о применении стандартной методологии и выборе
определенной методологии принимается совместно службой информационной системы и информационных технологий организации. Это
происходит, потому, что данная служба предполагает, что принятие
решения о выборе методологии определяется ее ролью и исключительным правом. В самом деле, существует мнение, что принятие на
себя технической компетенции является структурной основой власти
профессионалов по информационным системам в организации. Было
бы правильно полагать, что, в общем, такие решения должны принимать пользователи и бизнес менеджеры, т. к. они должны осуществлять такие инвестиции, не только в смысле денежных средств, но и
времени и усилий и, в конечном счете, в смысле успеха организации,
как результата принятых решений. Однако предположение, что такое
решение должно приниматься персоналом информационных технологий часто принимается и поддерживается остальной организацией.
Разработка информационных систем часто выглядит как технический
вопрос, который должны решать технические специалисты. В конце
концов, за что им платит организация.
Однако существуют примеры, когда службы информационных технологий пытались безуспешно вовлечь пользователей и менеджеров в
принятие решений касающихся методологий. Пользователи и менеджеры предпочли оставить это службе информационных технологий вопреки потенциально существенному их влиянию на степень вовлечения
пользователей в разработку и, в конечном счете, на будущий успех организации в целом. Существуют случаи, когда менеджеры и пользователи были полностью игнорированы при выборе методологии, и те в
результате отказались совместно участвовать в разработке.
Гарантируется ли организации успешная информационная система в результате использования методологии? Ответом на этот
143
вопрос является, несомненно, «нет». Тем не менее, такой ответ поднимает вопрос «что должна создать методология?» Если две группы
разработчиков используют одну и ту же методологию в подобных
проектах в среде одинакового типа, можно ли ожидать одинаковых
результатов, и если нет, то почему?
Ясно, что разработчики могут интерпретировать требования методологии по-разному и, таким образом, закончить работу с различным результатами. Методология может дать много свободы
действий для разработчиков в смысле выполнения определенных
задач, и, следовательно, результаты будут различными. Разработчики могут иметь отличающиеся уровни квалификации, которые
приведут к различным результатам. Тем не менее, часто утверждается, что многократное использование одной и той же методологии
в одинаковых обстоятельствах должно дать одинаковый результат.
Чем меньше свободы выбора методология оставляет разработчику,
и чем специфичнее методология, тем выше воспроизводимость ее
результатов, в частности, методологии, устанавливающие строгие
способы и средства для применения, обладают более высокой воспроизводимостью результата.
Область, связанная с воспроизводимостью результата, является
очень спорной, но вывод состоит в том, что если результаты являются в
некоторой степени воспроизводимыми, то можно быть уверенным, что
методология предлагает один из лучших способов создания информационной системы. Здесь нельзя сказать наилучший способ, потому что
могут существовать компромиссы между качеством, количеством,
уровнем квалификации, надежностью и т.п. Но все нуждаются в методологии, которая приводит к хорошим результатам. Это подразумевает,
что методология является не только полезным набором руководств,
предоставляющим возможность разработчику организовать процесс
разработки более результативно и эффективно, но и что она реализует
хороший способ разработки систем. Если существует воспроизводимость, то это ведет к разработке заслуживающих внимания решений и,
таким образом, если мы применим методологию, то она должна быть,
по нашему мнению, хорошим способом создания системы. Если нет, то
144
это приведет к ряду проблем, потому что природа методологии исключает другие способы ведения разработки.
Вопрос повторяемости или воспроизводимости явно не из тех, которые можно было бы легко проверить на практике. Невозможно создать точно такую же среду в организации для двух независимых
групп разработчиков, чтобы можно было сравнить разработанные
ими системы. В существующих исследованиях, освещающих эту
проблему, предполагалось, что две группы разработчиков могли бы
работать независимо над разработкой системы с одинаковыми требованиями в одинаковой среде для получения возможности обоснованного сравнения систем после окончания работ. Однако сам факт существования двух группы разработчиков, бесспорно, оказывает влияние на результат. Например, если одна из групп разработчиков первой проведет обсуждение с пользователями, то это окажет влияние на
обсуждение, проводимое в последующем другой группой.
Недостаток повторяемости, или, скорее, возможности доказательства повторяемости часто используется для выдвижения идеи, что
информационные системы не являются в действительности инженерной дисциплиной. Тем не менее, инженерное искусство является также творческой профессией. Спроектируют ли два инженера одинаково один и тот же мост или электронную схему для одной и той же
функции? Возможно, нет, но степень свободы в проектировании моста больше, чем при проектировании схемы. В информационных системах степень свободы обычно больше, чем для моста. Применение
методологии информационных систем может, таким образом, рассматриваться как попытка уменьшения степени этой свободы.
Если это правильно, то вывод по-прежнему состоит в том, что методология должна реализовывать один из лучших способов разработки систем. Это не всегда оценивается по достоинству при выборе методологий и может привести к разработке несоответствующих систем. Вопрос, реализует ли методология один из лучших способов,
задается редко. Более обычными задаваемыми вопросами являются
следующие:
145
x подходит ли она для существующего способа работы организации;
x определяет ли она требуемый выход в конце каждого этапа;
x улучшает ли она контроль и производительность;
x поддерживает ли она особый набор средств CASE.
Как было рассмотрено выше, существуют, вероятно, сотни различных методологий. Это значит, что существуют сотни «лучших»
способов разработки информационных систем. Многие из них после
близкого изучения оказываются довольно похожими, но многие действительно существенно отличаются.
3.5. Инфраструктура для сравнения методологий
Очевидно, сравнение методологий является трудной задачей и результаты такой работы всегда будут подвержены многократной критике. Существует столько же представлений методологий, сколько и
их авторов. Представления аналитиков не обязательно совпадают с
представлениями пользователей, и эти представления, в свою очередь, часто находятся в противоречии с представлениями авторов методологий. Таким образом, рассматриваемая ниже инфраструктура
для сравнительного анализа методологий является просто одним из
множества возможных представлений, которое, вряд ли, удовлетворит всех, имеющих отношение к данной области.
Представленная инфраструктура отражают изложенные выше
концепции и особенности методологий и основываются также на выполненных в данной области других исследованиях. Эта инфраструктура определяются рядом характеристик методологий разработки
информационных систем, ограничивающих область их анализа.
Предполагается, что инфраструктура, определяемая этими характеристиками, будет воспринята не только как академический подход, но
окажет практическую помощь в сравнении методологий. Предлагаемые характеристики состоят из семи представленных ниже основных
элементов, некоторые из них разбиты на подэлементы.
1. Философия: парадигма, цели, домен, целевой объект.
146
2. Модель.
3. Методы и средства.
4. Широта охвата.
5. Выходы.
6. Применение: истоки методологии, пользовательская база,
участники.
7. Продукт.
Эти характеристики не являются исчерпывающими и могут быть
дополнены рядом других свойств, учет которых мог бы быть полезным для конкретных целей. Используемые характеристики не являются взаимно исключающими, и очевидно, что между ними существуют взаимные отношения. Например, аспект философии отражен,
в некотором смысле, во всех других элементах.
Философия. Является важным аспектом методологии, потому что
она определяет все другие аспекты. Она больше, чем другие характеристики определяет отличие «методологии» от «метода». Выбор области, охватываемой методологией, систем, ориентации на данные
или на людей, степени компьютеризации и других аспектов определяются на основе философии методологии. Она может присутствовать в методологии явно, но в большинстве методологий философия
явно не выражена.
В контексте методологий философия рассматривается как принцип
или набор принципов, лежащих в основе методологии. Иногда полагают, что все методологии основываются на общей философии, которая направлена на улучшение мира разработки информационных систем. Это, в некоторой степени, справедливо, но не для того, что подразумевается под философией здесь.
Парадигма, или принцип, система понятий, признанные всеми
научные достижения, которые в течение определённого времени дают научному сообществу модель постановки проблем и их решений.
Анализ и классификация подходов в системном анализе позволяет
выделить две уместные здесь парадигмы. Первая – это парадигма
науки, которая характеризует большинство жестких научных разработок, наблюдаемых в конце XX столетия, и вторая – это парадигма
147
систем, которая характеризуется целостным подходом к системам деятельности человека.
Термин «парадигма» определяется как характерный способ рассуждения о проблемах, охватывающих множество достижений, которые признаны в качестве основы для будущего осуществления на
практике. Парадигма обычно рассматривается отвлеченно от объекта,
чтобы она могла применяться к множеству проблем, невзирая на их
специфическое содержание.
Парадигма науки состоит из редукционизма, повторяемости и
опровержения. Она утверждает, что можно снизить сложность разнообразия реального мира в экспериментах, результаты которых подтверждаются их повторяемостью, и построить знания, опровергая гипотезы.
Парадигма науки имеет длинную и успешную историю и определяет многое из нашего настоящего мира. Системная парадигма имеет
более короткую и менее успешную историю, она возникла в качестве
реакции на редукционизм науки и выявленную его неспособность
справиться с живыми системами и системами, классифицируемыми
как системы деятельности человека.
Наука справляется со сложностью через редукционизм, разделяя
вещи на меньшие и меньшие части для исследования и объяснения.
Это подразумевает, что деление на категории не разрушает систему,
частью которой они является. Полагают, что системы человеческой
деятельности не проявляют таких характеристик, они обладают эмергентными свойствами (эмергентный свойственный популяции в целом, но отсутствующий у её элементов, т. е. целое является большим,
чем сумма частей) и действуют различно, являясь целым или частью
системы, чем разделенные на отдельные компоненты. Открытие таких свойств привело к разработке парадигмы системы, которая характеризуется ее отношением к целой картине, эмергентным свойствам, и взаимоотношениям между частями целого.
Онтология связана с сущностью вещей и природой мира, и в ней
определяются две крайних точки зрения реализм и номинализм. Реализм постулирует, что мир содержит объективно существующие,
148
неизменные объекты и структуры. Они существуют как эмпирические объекты, сами по себе, независимо от понимания их наблюдателем. Номинализм проявляется, когда полагают, что реальность (действительность) является не неизменной, а социально (общественно)
созданной. Она результат человеческого сознания. Социальный релятивизм является парадигмой, принятой для понимания социальных
явлений и, главным образом, применяется для объяснения социального мира с точки зрения представителей организаций, которые непосредственно принимают участие в социальном процессе создания реальности.
Эпистемология это раздел философии, изучающий основы знаний. Этот термин имеет отношение к способу, при помощи которого
может быть правильно исследован мир, и тому, что может рассматриваться как знания и прогресс. Она включает элементы, касающиеся
источников знаний, структуры знаний и границ того, что может быть
известно. В эпистемологии существуют две крайних точки зрения –
это позитивизм и интерпретивизм. Позитивизм подразумевает существование отношений причины, которые могут быть исследованы с
помощью научного метода, тогда как интерпретивизм подразумевает,
что не существует единой истины, которая может быть доказана такими исследованиями. Различные представления и интерпретации
являются потенциально допустимыми, и путь к прогрессу состоит не
в попытке и раскрытии одного «правильного» представления, а в
признании различий и в стремлении к увеличению проникновения
посредством глубокого понимания такой сложности.
Рассмотренные элементы, сведенные вместе, могут составить систему взглядов (рис. 3.1), которая определяет объективисткий и субъективисткий подходы, как некоторые положения между онтологией
реализма и номинализма и эпистемологией позитивизма и интерпретивизма. Эта система взглядов представляется полезной для размышления и определения основополагающих философий методологий.
Например, если мы придерживаемся онтологии номинализма, мы не
должны не принимать методологии, основанные на допущениях реализма. Субъективистский подход мог бы оказать помощь в восприя149
тии нами данных, собранных при анализе системы не как фактов, а
больше как образов различных точек зрений. Планы продаж не обязательно являются набором фактов, а возможно, частью политического
процесса, который согласован между торговым персоналом, менеджментом и директорами. Это соглашение может иметь далеко идущие
последствия, имеющие отношение к существованию людей, их жалованию, удовлетворенности трудом, самооценке и т. п. Кроме того,
нам необходимы способы управления этими различными образами
нашего восприятия. Это может означать, например, что мы нуждаемся в методологии, которая концентрируется на выделении различных
мнений и толкований, или которая предоставляет серии различных
дизайнов для обеспечения различных восприятий.
Позитивизм
Объективистский
подход
Эпистемология
Субъективистский
подход
Интерпретивизм
Реализм
Номинализм
Онтология
Рис. 3.1. Основа для анализа философии методологий
Рассмотренные предположения поднимают некоторые интересные
вопросы, т. к., если широко распространенный объективистский метод может быть использован в субъективистском способе, тогда подразумевается, что сам по себе метод не является такой важной особенностью в определении характеристик методологии, как обычно
считают. Однако мы могли бы полагать, что модели объектов не ис150
пользуются широко в субъективистском способе, но даже если они
могут использоваться, метод все же остается объективистским, потому что он продвигает пользователя метода в этом общем направлении. Надо быть искушенным разработчиком, чтобы не пытаться согласовать отличающиеся представления одного и того же варианта
реальности. Тем не менее, можно утверждать, что не столь важно,
предполагает ли метод независимое существование реальности или
согласованную интерпретацию реальности, как то, способен ли он
обрабатывать отличающиеся восприятия реальности, которые не могут быть разрешены согласованием.
Это комплексная область, но цель ее рассмотрения состояла в том,
чтобы показать важность основополагающих философий методологий и допущений и что разработчикам необходимо осознавать необходимость согласования своих убеждения с убеждениями авторов методологий. Как это очевидно, вышеприведенное рассмотрение онтологии и эпистемологии является существенным упрощением давней
философской полемики, более полные сведения могут быть получены
из специальной литературы на эту тему.
Цели. Явно очевидный ход мыслей философии, принятой методологией, определяется ее установленной целью или целями. Некоторые
методологии утверждают, что их целью является разработка автоматизированной информационной системы. Другие, например, ISAC, ставят своей целью исследование того, существует ли действительно потребность в информационной системе. Следовательно, между методологиями существует различие, которое заключается в том, что некоторые из них заинтересованы только в аспекте «компьютеризуемости», в
то время как другие имеют более широкую точку зрения и направляют
свое внимание на получение решений или улучшений независимо от
того к каким последствиям приведет результат. Такие улучшения могут привести к ручным, процедурным, управленческим, организационным, образовательным или политическим изменениям. Это является
важным различием, потому что оно определяет границу рассматриваемой области. Проблема концентрации только на компьютеризируемых аспектах состоит в том, что создаются искусственные границы
151
логики бизнеса. Не существует причины, почему решение проблемы
данного вида должно принадлежать только той области, которая может быть автоматизирована. Более вероятно, что проблема нуждается
в исследовании в более широком контексте.
Часто обнаруживают, что «компьютеризация» сама по себе не дает
желаемого результата организации. На самом деле требуется всесторонний анализ и ре-дизайн проблемной области в целом. Рассмотрение компьютеризации как некоторого решения конкретной проблемы
выглядит как попытка «поместить телегу впереди лошади». Ясно, что
методология, которая касается только анализа потребности в компьютерном решении, сильно отличается от той методологии, которая не
делает это. При выборе и осмыслении методологии, возможно, было
бы хорошо задать вопрос: «Могло бы использование этой методологии привести к внедрению чисто организационного или ручного решения?». Если ответом будет «нет», то, следовательно, эта методология не рассматривает те же проблемы, как та, у которой ответом является «да». Интересно отметить, что многие из большинства широко
используемых коммерческих методологий могли бы, кажется, ответить «нет» на этот вопрос, в то время как большинство академических методологий, вероятно, ответили бы «да». Исключение могли
бы составлять современные BPR методологии, которые концентрируются не конкретно на компьютеризации, а на улучшении бизнеспроцессов, которые на практике часто требуют не компьютеризированных перемен.
Домен. Третьим фактором, имеющим отношение к философии,
является домен, или область ситуаций, рассматриваемых методологией. У первые методологии, таких как подход традиционного жизненного цикла, была задача преодоления конкретной и иногда узкой
проблемы. Очевидно, решение проблемы, часто через внедрение некоторого вида компьютерной системы, могло бы быть выгодным для
организации. Однако принятие решений по нескольким проблемам
такого вида на основе узкого применения в различное время может
привести к «месиву» различных физических информационных систем, находящихся в эксплуатации в одно и то же время.
152
Даже если разработка решений для различных проблем хорошо
скоординирована и очередная такая система будет создана по подобию системы, созданной ранее, часто обнаруживают, что на самом
деле системы и проблемы взаимосвязаны и решение, принятое по ряду взаимосвязанных проблем, отличается от суммы решений, принятых по отдельным проблемам, рассмотренным индивидуально.
Это положило начало ряду методологий, принимающих другую
философию разработки. Они полагают, что для решения отдельных
проблем необходимо выполнить анализ организации как единого целого, разработать стратегию информационной системы в целом, классифицировать данные и ресурсы организации и идентифицировать
пересекающиеся области и области, нуждающиеся в интеграции. По
существу, необходимо провести нисходящий анализ организации,
выявить стратегические требования бизнеса и таким способом обеспечить, поддержку этих фундаментальных требований разрабатываемой информационной системой.
Целевой объект. Последним аспектом философии является применяемость методологии. Некоторые методологии определенно
направлены на конкретный тип проблем, среды или тип или размер
организации, в то время как другие, как говорят, имеют общее назначение.
Модель. Вторая характеристика, используемая для сравнения методологий, касается моделей, применяемых методологиями. Модель
является основой отображения методологией реального мира, она является абстракцией и представлением важных аспектов информационной системы или организации.
Модели применяют на ряде уровней, во-первых, модель это
средство коммуникации, во-вторых средство захвата существа проблемы или дизайна, так что она может быть транслирована или отображена в другую форму (например, внедрение) без потери подробностей, в-третьих, модель является представлением, которое обеспечивает проникновение в проблему или интересующую область.
Модели могут быть подразделены на четыре различных типа:
x словесные;
153
x аналитические или математические;
x изобразительные, графические или схематические;
x имитационные.
Рассматриваемые модели в области методологий информационных
систем являются исключительно моделями третьего типа, хотя существуют методологии, не рассматриваемые в данном пособии, например, ACM/PCM, использующие модели второго типа. Причина преобладания моделей третьего типа состоит в осознании важности использования моделей как средства коммуникации, в частности, между пользователями и аналитиками. Остальные важные аспекты моделей в разработке информационных систем состоят в обеспечении того, чтобы на соответствующем этапе вырабатывалась необходимая
информация и чтобы эта информация являлась той, которая требуется
для создания работающей системы.
Как было установлено, модель является формой абстракции. Абстракция обычно рассматривается как процесс отделения идеи или системы от ее конкретных или физических свойств. Абстракция может
рассматриваться как любое упрощение систем и объектов на любом
уровне, например, логическое представление физического объекта.
Выгода от абстракции состоит в облегчении разработки сложных
приложений. Она обеспечивает способ рассмотрения важных аспектов систем на различных уровнях, поэтому высокий уровень абстракции содержит «существо» системы и нижние уровни представляют
подробности, которые не противоречат этому «существу». Процесс
«отделения» приводит к потере информации и, следовательно, модель должна терять только ту информацию, которая не является частью существа системы.
Абстракция тесно связана с иерархической декомпозицией. Каждый уровень декомпозиции обеспечивает абстрактное представление
более низких уровней в том смысле, что подробности подчинены более низким уровням. Для повышения результативности каждый уровень в декомпозиции должен быть понятным как блок, не требующий
знания ни подробностей более низких уровней, ни того, как он участвует в системе, при рассмотрении вышележащего уровня иерархии.
154
Выбор уровней, при помощи которых определяется система, зависит от целей исследования и дизайна, но считается, что существуют
некоторые «естественные» или «природные» уровни и традиционно
ими являются концептуальный, логический и физический (рис. 3.2).
Реальный мир
Предметная область
Концептуальная
модель
Логическая
модель
Уровени
абстракции
Физическая
модель
Рис. 3.2. Трехуровневая схема моделирования
Концептуальный уровень – это описание предметной области или
предметной системы на высоком уровне в соответствии с каким-то
конкретным представления. В нашем случае представлением могли
бы быть информационные системы или бизнес системы, или общество. Описание может быть статическим или динамическим, или
комбинацией обоих. Некоторые исследователи рассматривают концептуальную модель как определение структуры проблемы информационной системы, подобно тому, как карта определяет структуру
проблемы транспортной системы. Она также может рассматриваться
как выведенные «уравнения» приложения. Эта система «уравнений»
155
составляет основу для различных решений обработки. Не существует
прямого соответствия ни между состоянием предметной системы и
содержанием базы данных будущей информационной системы, ни
между правилами вывода и ее процессами.
Таким образом, концептуальная модель не предполагает ни какого-нибудь конкретного содержания базы данных, ни действий по обработке. Концептуальные модели вызывают большую путаницу, т. к.
этот термин используется различным образом даже в методологиях.
Одна из причин состоит в том, что язык концептуального моделирования иногда является таким же, как и логического моделирования.
Модель объектов часто характеризуется как концептуальная модель,
и это может быть так, но необходимо помнить, что при этом она описывает предметную область, и не обязательно будет являться частью
информационной системы.
Логический уровень представляет описание информационной системы без каких-либо ссылок на технологию, которая могла бы быть
использована для его реализации. Он охватывает саму информационную систему и не касается прикладной области. Основная цель логической модели состоит в обеспечении спецификации требований к
информационной системе.
Физический уровень представляет описание информационной системы, включая технологию ее конкретной реализации.
Кроме форм, определяющих информационные системы, в общем,
существует и другие формы абстракции. Например, хорошо известная семантическая иерархическая модель для разработки приложений
баз данных. Она определяет 4 формы абстракций: классификацию,
агрегацию, обобщение и ассоциацию. Эти 4 формы абстракции дают
возможность осуществлять интеграцию моделирования данных и
процессов, позволяя определять ограничения целостности одновременно с определением данных.
Методы и средства. Ключевой характеристикой, используемой
для сравнения методологий, является идентификация методов и
средств, используемых методологией. Однако уже существующее их
многообразие, а также очевидная необходимость их дальнейшего
156
разрастания, совершенствования и систематизации (см. материал главы 1) требуют подробного рассмотрения данной темы отдельно.
Широта охвата. Широта охвата методологии является признаком
этапов жизненного цикла разработки рассматриваемых методологией. Более того, считается также важным тот уровень подробности, на
котором методология рассматривает каждый этап. Проблема с использованием этапов жизненного цикла как основы для исследования
широты охвата состоит в том, что не существует полного согласия по
вопросу что является или что должно считаться этапом цикла. Это,
возможно, является проблемой, которая может быть преодолена, потому что большинство разновидностей жизненного цикла различных
методологий могут быть взаимно отображены.
Более серьезная проблема состоит в том, что некоторые авторитетные специалисты в области информационных систем характеризуют жизненный цикл как непригодный для потребностей разработчиков информационных систем. Они считают, что разработка и широкое распространение средств быстрой разработки приложений (макетирование) изменила традиционную картину, и что применение
жизненного цикла ограничивает разработку, приводя ее к негибкой
модели, и сохраняет навсегда неспособность промышленности к созданию эффективного моста между пользователем и аналитиком.
Фактически они высказывают две мысли:
x процесс разработки сильно ускоряется и пользовательские восприятия того, что возможно и желательно, изменяются в течение разработки. Анализ требований не должен заканчиваться рано в разработке проекта информационных систем, а должен проходить через весь процесс;
x конечным результатом макетирования мог бы быть дизайн желаемой системы, и что это затем могло бы быть специфицировано для
разработки средствами обычного языка программирования. В этом
случае результат дизайна получается раньше, чем спецификация, что
сильно отличается от представления нормального жизненного цикла.
В противовес такому представлению «жизненного цикла как пагубного» существуют идеи, что макетирование могло бы быть встроено в подход жизненного цикла систем.
157
Выходы. Следующая характеристика, используемая для сравнения
методологий разработки информационных систем, касается выходов
методологии. Очень важно знать, что каждая методология предусматривает определение выходов каждого из ее этапов и, в частности,
выход завершающего этапа, являющийся, в сущности, завершающим
выходом методологии может варьироваться от спецификаций анализа
до реализации информационной системы.
Применение. Эта характеристика оценивается в соответствии с
истоками методологии, пользовательской базой (включая количество
и типы пользователей), участниками методологии (например, может
ли она использоваться самими пользователями или требует привлечения профессиональных аналитиков), и уровнем их квалификации.
Оцениваются также трудности и встречающиеся проблемы, а также
успешность применений и неудачи. Оценка определяется путем исследования предшествующего опыта пользователей методологии. Это
будет неизбежно субъективно, в зависимости от того, кто будет консультировать. При исследовании применения должна быть оценена
степень, с которой методология может быть изменена или интерпретирована пользователями в соответствии с требованиями конкретной
ситуации. Также важно оценить проявляющиеся различия между
применением и теорией методологии.
Продукт. Последняя из рассматриваемых характеристик – продукт – это то, что покупатели фактически получают, приобретая методологию. Он может включать в себя программные средства, документацию и согласованное количество часов обучения, телефонное
справочное обслуживание, консультирование и т. п.
3.6. Сравнение методологий
Этот параграф рассматривает некоторые из упомянутых выше методологий в контексте инфраструктуры для сравнения методологий, предложенной в предыдущем параграфе. Выбор методологий для приведенного ниже сравнения можно назвать избирательным: в него вошли
наиболее известные методологии, отражающие совместно все многооб158
разие специфики подходов и охватывающие весь диапазон возможностей, обеспечиваемых существующими методологиями. Обзор не включает Multiview, потому что она объединяет аспекты многих других методологий, RAD, потому что она тесно связана с IE, KADS, потому что
она имеет узкое применение (разработка экспертных систем) и Euromethod, потому что она представляет собой определение рамок для
стандартов методологий. Рассматриваемый обзор не претендует на всеобъемлемость и не должен восприниматься как некоторое утверждение
«фактов» о методологиях. Он скорее дает субъективное представление и
определяет начальную точку для последующего обсуждения.
Первая характеристика касается идентификации философии методологии. Существует ряд подэлементов философии, первым из которых является парадигма, которая обеспечивает понимание трудностей попыток сравнения методологий. При рассмотрении рамок сравнения методологий были отмечены две наиболее важные парадигмы
парадигма науки и парадигма систем. На основании изучения методологий можно полагать, что SSM и ETHICS соответствуют парадигме систем и что STRADIS, YSM, IE, SSADM, Merise, JSD, OOA и
ISAC соответствуют парадигме науки.
SSM придерживается парадигмы систем, т. к. это явно заявляется
автором методологии. Это один из малочисленных случаев, когда
данный вопрос рассматривается как часть самой методологии. Но
даже не зная того, ясно, что методология использует многие из системных концепций и не принимает редукционистский подход.
В ETHICS демонстрируется вера во взаимодействие социальных и
технических подсистем (социо-технический подход), которая пропагандирует философию дизайна с участием персонала. Исследуются
противоречия или недостатки работающей системы, препятствующие
осуществлению целей системы. Эти противоречия часто выявляются
на границах подсистем, в частности, на стыках социальных и технических подсистем. Идеи повышения разнообразия работ и дизайна с
участием персонала являются особенностью решений для более общих выявленных противоречий. В дополнение, ETHICS не делает попытки разбиения системы на ее составные части с целью постижения
159
проблем. Таким образом, это доказывает, что основополагающей парадигмой ETHICS также является парадигма систем.
При анализе парадигмы ISAC представляет наибольшую проблему
и вызывает наибольшие споры. ISAC часто рассматривается как «методология с участием персонала». Утверждается, что ISAC основана
на признании важности людей в организации. Это включает всех людей, например, конечных пользователей, открытых или публичных
пользователей, пользователей, предоставляющих фонды. Для преодоления многочисленных проблем работа, которую должны выполнять
эти люди, нуждается в улучшении, и лучшим образом справиться с
такой задачей могут сами пользователи. Рассматриваемая методология помогает людям сделать это.
То, что ISAC твердо придерживается традиций участия, не означает автоматически, что она придерживается парадигмы систем. Методология ETHICS также сильно ориентирована на участие персонала,
но она рассматривает социо-технические аспекты, что доказывает ее
приверженность парадигме систем. ISAC также применяет крайне редукционистский подход для понимания системы. Ее автор утверждает, что единственный путь решения сложных проблем состоит в разделении их на подпроблемы до тех пор, пока они не станут «поддающимися управлению». Это должно выполняться при условии, что решение подпроблем дает решение для проблемы в целом, т.е. что разделение на подпроблемы должно быть согласованным.
Это могло бы казаться ясным подтверждением приверженности
парадигме науки и неприятием концепции эмергентных свойств. Но,
с другой стороны, существует ряд областей, где ISAC принимает некоторые идеи системного мышления, такие как иерархия систем. Она
признает необходимость понимания более широких проблем и смысла, чем это определяют границы системы. Однако ISAC следует классифицировать как методологию, принимающую парадигму науки, хотя если придерживаться понятия континуума, он занимает там не самое крайнее положение.
На основе их явно редукционистских подходов и признания онтологических положений реализма STRADIS, YSM, IE, SSADM, Merise,
160
JSD и OOA соответствуют парадигме науки. IE, например, применяет
то, что в ней называется подходом «разделяй и властвуй», который
является чисто редукционистским. JSD характеризует свой подход к
моделированию как попытку отражения состояния реального мира,
например, на шаге действия объектов определяются объекты реального мира без каких-либо исследований социального устройства реального мира или каких-нибудь проблем, с которыми можно было бы
столкнуться, касаясь отличающихся восприятий реального мира.
Второй подэлемент философии касается целей методологии. Существует много целей методологий, которые можно было бы обсудить,
но в данном случае представляется более важным рассмотреть, поставлена ли перед ним цель построения автоматизированной информационной системы, или направлены ли они на дальнейшее улучшение и более общее разрешение проблем организации. Во многих методологиях цель выражена яснее, чем в других. ISAC, например, рассматривает разработку информационной системы как соответствующее мероприятие разработки, только если анализ перемен показывает,
что существуют проблемы и потребности в области информационных
систем. В других ситуациях выбираются другие мероприятия разработки, например, разработка непосредственно бизнес деятельности,
такой как производство, продукт или распределенная система или разработка организации. Исходя из рассмотренного, видно, что цель методологии ISAC представляет собой намного больше, чем разработка
автоматизированной системы. Process Innovation (PI) также имеет цели, которые намного шире чем разработка автоматизированных систем. Ее цели направлены на улучшение и ре-дизайн бизнес процессов
в целом для организации, и хотя информационные технологии обычно
рассматриваются как важное средство рационализации процессов,
многие из выявленных улучшений и процессов ре-дизайна выполняются без конструирования компьютерной системы.
С другой стороны, STRADIS, YSM, IE, SSADM, Merise, JSD и
OOA могут быть отнесены не к классу методологий разрешения общих проблем, а к методологиям, имеющим ясно выраженные цели
создания автоматизированных информационных систем. В некоторых
161
методологиях утверждается, что они применимы независимо от того
будет или нет автоматизироваться система, например, STRADIS, но
свидетельства того, что это когда-либо применялось на практике, не
было обнаружено. Исследование действия этих методологий показывает, что их основное направление явно включает посылку построения автоматизированной системы.
Следующим элементом анализа является домен. Он связан с рассмотренным выше подэлементом «цель», но концентрируется на том,
какие аспекты или домены пытается рассматривать методология.
Наиболее интересными являются различия между теми методологиями, которые стремятся определить для информационной системы потребности бизнеса и организации, т. е. те, которые рассматривают
общее планирование, организацию и стратегию информации и системы в организации, и те, которые касаются разрешения специфических,
заранее определенных проблем, например, потребность в маркетинговой информации для торгового персонала. Обычно ключом в таком
случае является начальная точка методологии. IE, Process Innovation и
SSM определяются как методологии типа «планирование, организация
и стратегия». В методологии Process Innovation разработка информационной системы явно управляется идентифицированными улучшениями
процессов, требуемыми организацией и ее бизнесом для получения
преимущества. Первый этап IE связан с планированием информационной стратегии. Здесь осуществляется обзор организации в терминах целей бизнеса и связанных с ними информационных потребностей и разрабатывается в целом план информационных систем для организации.
Это показывает, что данный подход принимает философию, состоящую
в том, что организация нуждается в таком плане для эффективного
функционирования, и что ее успех связан с идентификацией информационных систем, которые принесут выгоду организации и окажут помощь в достижении стратегических целей.
SSM сильно отличается от IE, и все же она может быть отнесена к
типу методологий «планирование, организация и стратегия». Эту
терминологию, возможно, не очень просто связать с SSM, но это явно
не методология для решения специфических проблем т. к. в своей от162
правной точке она не предполагает существования уже хорошо определенной структурированной проблемы. Многие из возможностей
SSM направлены на понимание этих широких положений и контекста
существующей проблемной ситуации. Термин «проблемная ситуация» в SSM не включает в себя существование хорошо определенной
проблемы, совсем наоборот. Однако SSM обычно не представляется
как методология, которая рассматривает планирование, организацию
и стратегию, но если убрать управленческий смысл из этих терминов,
то это, по существу, является тем, что она рассматривает. Она пытается идентифицировать основополагающие вопросы, которые помогают в понимании проблемной ситуации, включая стремление организации. Последующие шаги методологии определяют осуществимость, а также желательные перемены и рекомендуемые действия для
улучшения ситуации, результатом которых может быть разработка
информационной системы.
STRADIS, YSM, SSADM, Merise, JSD, OOA, ISAC и ETHICS могут быть классифицированы как специфические методологии решения проблем. Они не концентрируются на идентификации системы,
требуемой организацией, и начинают с допущения, что должны быть
рассмотрены специфические проблемы.
Завершающий подэлемент философии касается разрабатываемой
целевой системы, т. е. направлена ли методология на определенный
тип приложений, или тип проблем, размер систем, среды и т. п. Это
является также трудной задачей, потому что большинство методологий преподносятся как методологии общего назначения. Такое
утверждение явно действует в рамках определенных допущений. В
большинстве случаев методологии направлены на решение проблем
большой организаций с внутренней службой обработки данных. Далее, часто предполагается, что методология рассматривает разработку
заказных систем, а не использование прикладных пакетов. Исключение составляет IE, где исследуются альтернативные подходы. OOA
рассматривается как методология общего назначения, хотя предполагается, что она не очень полезна для простых ограниченных систем,
включающих только несколько классов и объектов. STRADIS также
163
определена как методология общего назначения, применимая к системам любого размера, хотя его основной метод схем потоков данных не очень хорошо подходит для всех типов приложений, например для разработки систем управленческих отчетов. Таким образом,
заявления авторов методологии должны быть проверены путем исследования самой методологии. JSD, например, описана как наиболее
подходящая для приложений обработки реального времени. SSM разработана для применения в сложных проблемных ситуациях человеческой деятельности.
Размер организации, рассматриваемой методологией, является
также важным аспектом целевой системы. Тогда как STRADIS, YSM,
IE, SSADM и Merise разработаны все в основном для использования в
больших организациях, Multiview был разработан также для применения в относительно малых организациях. Существует также версия
SSADM, называемая MicroSSADM, которая предназначена для помощи в разработке систем в меньшей среде или для целевых систем,
основанных на персональных компьютерах.
Вторая характеристика инфраструктуры для сравнения методологий имеет дело с моделями, используемыми методологией. Могут
быть исследованы разнообразные стороны моделей, включая тип модели, уровни абстракции модели и ориентацию или направленность
модели.
Ограничимся рассмотрением только моделей процессов, используемых методологиями разработки информационных систем. Схему потоков данных можно считать моделью первостепенной важности среди моделей процессов, используемых в методологиях. В STRADIS
она является исходной моделью методологии. Она также используется в YSM, SSADM и ISAC как важная модель, хотя и не является
единственной. Она также используется в некоторых модификациях
SSM и представлена в IE, хотя в немного отличающейся форме,
названной схемой зависимости процессов, но здесь она выполняет
менее значительную роль, чем, например, в STRADIS. Схема потоков
данных является преимущественно моделью процессов, данные в ней
моделируются только как сопутствующий продукт процессов.
164
Модели в JSD, ETHICS, SSM и Process Innovation являются также
процесс-ориентированными, но они не используют схем потоков
данных. Структурные диаграммы, используемые в JSD для моделирования аспектов процессов, предоставляют изображение структуры
процессов, а не потоки данных между процессами, что существенно
перемещает внимание на то, что является важным в JSD и помогает
объяснить, почему эта методология рассматривается как более подходящая для приложений реального времени, чем методологии, использующие схемы потоков данных. ETHICS использует социотехническую модель, которая затрагивает взаимодействие технологий, людей и выполняемый процесс.
Третий элемент инфраструктуры имеет отношение к методам и
средствам, используемым методологией. Методы, используемые в методологии, обычно ясны, что позволяет легко осуществлять их сравнение и противопоставление. Многие из моделей, рассмотренных выше,
непосредственно отражены в методах методологий, но иногда существуют отличия в способе использования моделей и их значение в методологии. Многие методологии возникли на основе нового созданного
метода, рассматриваемого затем как часть методологии. STRADIS является примером методологии, которая в большинстве описана в терминах ее методов, другие, такие как YSM, SSADM и JSD, также имеют
специфические методы, которые рассматриваются как основа созданной на них методологии. Другие методологии, например, ISAC, не зависят так сильно от конкретных методов, и она относительно легко
предусматривает подобные, но альтернативные методы, используемые
без нарушения существа методологии.
В некоторых методологиях, например, IE, высказывается явно, что
методы не являются существенной частью методологии и что текущие рекомендованные методы могут быть замещены при возникновении лучших. Это является потенциально важным концептуальным
различием между методологиями. Понятно, что методологии, которые позволяют встраивать новые методы, являются отчасти более
гибкими, но достичь этого на практике очень трудно. Например, в
методологии, которая выступает за полное разделение моделирова165
ния данных и процессов, таких как SSADM, Merise или IE было бы
очень трудно приспособить объектно-ориентированное моделирование, которое интегрирует данные и процессы, без внесения изменений в основы методологии. В таких случаях идентификация основ
является важной частью любого сравнения. Это также поднимает вопросы о том, как могут правильно разрабатывать и развивать во времени методологии без потери их сущности.
Сравнение средств методологий начинается с определения того, рекомендует ли она особо какое-то из средств компьютерной поддержки.
SSM, например, не рекомендует, или даже не упоминает, какое-нибудь
средство, но большинство методологий YSM, IE, SSADM, Merise, JSD,
OOA и Process Innovation, рекомендуют в некоторой степени использование средств. Компьютерная поддержка колеблется от простых вычерчивающих средств до средств, обеспечивающих автоматизацию всего процесс разработки, включая макетирование, управление проектом,
генерацию кодов, моделирование и т.п. Степень рекомендации значительно различается. Некоторые, такие как IE, считают, что процесс не
должен рассматриваться без использования средств, т. к. в этом случае
он сильно осложняется и увеличиваются затраты времени. Другие,
например, SSADM и OOA, полагают, что они (средства) могли бы быть
полезными, но не являются существенно необходимыми.
Четвертый элемент инфраструктуры – это широта охвата методологии. Исследуя «этапы жизненного цикла» рассматриваемых методологий, можно установить девять этапов: стратегия (планирование), осуществимость, анализ, логический дизайн, физический дизайн, программирование, тестирование, внедрение и сопровождение. Такой
подход для анализа широты методологий не является единственно
возможным, и в зависимости от сравниваемых методологий и целей
сравнения могут быть выбраны другие более подходящие размерности. Любой анализ широты охвата методологий является трудным и
субъективным. Использование этапов жизненного цикла может быть
не интересным для тех методологий, которые не созданы для повторения такой структуры, например, методологии макетирования, в случае
которой определение широты, основанное на спиральной модели,
166
ɦɨɝɥɨ ɛɵɬɶ ɛɨɥɟɟ ɚɞɟɤɜɚɬɧɵɦ. ɋɥɟɞɨɜɚɬɟɥɶɧɨ, ɜɚɠɧɨ, ɱɬɨ ɲɢɪɨɬɚ ɧɟ
ɪɚɫɫɦɚɬɪɢɜɚɟɬɫɹ ɜ ɢɡɨɥɹɰɢɢ ɨɬ ɞɪɭɝɢɯ ɯɚɪɚɤɬɟɪɢɫɬɢɤ ɦɟɬɨɞɨɥɨɝɢɣ.
ɇɚ ɪɢɫ. 3.3 ɩɪɟɞɫɬɚɜɥɟɧɵ ɪɟɡɭɥɶɬɚɬɵ ɚɧɚɥɢɡɚ ɲɢɪɨɬɵ ɨɯɜɚɬɚ ɦɟɬɨɞɨɥɨɝɢɣ. Ɂɚɲɬɪɢɯɨɜɚɧɧɵɟ ɨɛɥɚɫɬɢ ɩɨɤɚɡɵɜɚɸɬ, ɱɬɨ ɦɟɬɨɞɨɥɨɝɢɹ ɪɚɫɫɦɚɬɪɢɜɚɟɬ ɫɨɨɬɜɟɬɫɬɜɭɸɳɢɣ ɷɬɚɩ ɜ ɬɚɤɢɯ ɩɨɞɪɨɛɧɨɫɬɹɯ, ɤɨɬɨɪɵɟ ɦɨɝɭɬ ɜɤɥɸɱɚɬɶ ɨɛɟɫɩɟɱɟɧɢɟ ɩɨɞɞɟɪɠɢɜɚɸɳɢɦɢ ɦɟɬɨɞɚɦɢ ɢ ɫɪɟɞɫɬɜɚɦɢ.
Ɋɢɫ. 3.3. ɒɢɪɨɬɚ ɨɯɜɚɬɚ ɦɟɬɨɞɨɥɨɝɢɣ
ɇɟɡɚɲɬɪɢɯɨɜɚɧɧɚɹ ɨɛɥɚɫɬɶ ɨɡɧɚɱɚɟɬ, ɱɬɨ ɦɟɬɨɞɨɥɨɝɢɹ ɪɚɫɫɦɚɬɪɢɜɚɟɬ
ɨɛɥɚɫɬɶ, ɧɨ ɜ ɦɟɧɶɲɢɯ ɩɨɞɪɨɛɧɨɫɬɹɯ ɢ ɦɟɧɟɟ ɝɥɭɛɨɤɨ. ȼ ɷɬɨɦ ɫɥɭɱɚɟ
ɨɧɚ ɩɪɟɞɨɫɬɚɜɥɹɟɬ ɦɟɧɶɲɟ ɪɭɤɨɜɨɞɫɬɜɚ ɢ ɞɚɟɬ ɛɨɥɶɲɟ ɫɜɨɛɨɞɵ ɪɚɡɪɚɛɨɬɱɢɤɚɦ ɜ ɬɨɥɤɨɜɚɧɢɢ ɢ ɜɵɩɨɥɧɟɧɢɢ. ɉɭɧɤɬɢɪɧɵɟ ɥɢɧɢɢ ɨɛɨɡɧɚɱɚɸɬ
ɨɛɥɚɫɬɢ, ɤɨɬɨɪɵɟ ɬɨɥɶɤɨ ɤɪɚɬɤɨ ɭɩɨɦɢɧɚɸɬɫɹ ɜ ɦɟɬɨɞɨɥɨɝɢɢ, ɧɨ ɧɢɤɚɤɢɯ ɩɪɨɰɟɞɭɪ, ɦɟɬɨɞɨɜ ɢɥɢ ɩɪɚɜɢɥ ɧɟ ɨɛɟɫɩɟɱɢɜɚɸɬ, ɯɨɬɹ ɦɟɬɨɞɨɥɨɝɢɹ
ɩɪɢɡɧɚɟɬ, ɱɬɨ ɷɬɚ ɨɛɥɚɫɬɶ ɞɨɥɠɧɚ ɪɚɫɫɦɚɬɪɢɜɚɬɶɫɹ. ɇɚɥɢɱɢɟ ɥɸɛɨɝɨ ɢɡ
ɪɚɫɫɦɨɬɪɟɧɧɵɯ ɨɛɨɡɧɚɱɟɧɢɣ ɧɚ ɪɢɫ. 3.3 ɭɤɚɡɵɜɚɟɬ ɧɚ ɬɨ, ɱɬɨ ɦɟɬɨɞɨɥɨɝɢɹ ɪɚɫɫɦɚɬɪɢɜɚɟɬ ɤɨɧɤɪɟɬɧɭɸ ɨɛɥɚɫɬɶ, ɧɨ ɷɬɨ ɧɟ ɨɛɹɡɚɬɟɥɶɧɨ ɨɡɧɚɱɚɟɬ,
ɱɬɨ ɜ ɧɟɣ ɫɭɳɟɫɬɜɭɟɬ ɷɬɚɩ ɫ ɭɤɚɡɚɧɧɵɦ ɧɚɢɦɟɧɨɜɚɧɢɟɦ, ɚ ɬɨ, ɱɬɨ ɜɧɭɬɪɢ ɦɟɬɨɞɨɥɨɝɢɢ ɫɭɳɟɫɬɜɭɸɬ ɷɥɟɦɟɧɬɵ, ɤɨɬɨɪɵɟ ɦɨɝɭɬ ɛɵɬɶ ɢɫɬɨɥɤɨɜɚɧɵ ɤɚɤ ɷɤɜɢɜɚɥɟɧɬɧɵɟ ɪɚɫɫɦɚɬɪɢɜɚɟɦɨɦɭ ɷɬɚɩɭ.
167
В представленном анализе широты охвата стратегия используется для обозначения того, рассматривает ли методология какие-нибудь
аспекты, связанные с широким организационным контекстом, имеющим дело с общей стратегией информационных систем, целью и планированием. IE и PI определены как методологии, рассматривающие
«стратегию» в некоторых подробностях, как и SSM, которая также
имеет дело с более широким контекстом, хотя существенно отличающимся способом. SSADM, Merise и YSM тоже включают в себя аспекты стратегической природы.
Следующим этапом является осуществимость, которая определяется
как экономическая, социальная и техническая оценка рассматриваемой
системы. STRADIS, YSM, SSADM и Merise включают подробные аспекты для оценки осуществимости в своих методологиях. IE, ISAC и PI
также рассматривают осуществимость, но менее исчерпывающе. Однако
следует отметить, что способ, которым они рассматривают осуществимость, существенно отличается. Например, ISAC не включает в себя
специфическую фазу осуществимости (она содержится в некоторых шагах анализа), а STRADIS проверяет и перепроверяет осуществимость на
многих этапах методологии. ETHICS и SSM определены как методологии, подробно рассматривающие осуществимость, хотя и способом,
вполне отличающимся от других, т. к. рассматриваемая ими осуществимость перемен является не финансовой, а социальной. ETHICS концентрируется на социальном и техническом соответствии, а SSM – на осуществимости и желаемых переменах. На рис. 3.3 эти методологии обозначены как оконтуренные, но не заштрихованные области, т. к., хотя их
социальный аспект является и исчерпывающим, остальные нет.
Этап анализа, который включает в себя анализ требований пользователей, охватывается в подробностях всеми методологиями при помощи широкого многообразия различных способов. Однако в JSD
анализ требований пользователей рассматривается не явно, тем не
менее, эта методология начинает с допущения, что требования пользователя уже известны и даны. Этапы логического дизайна предусматриваются в подробностях всеми методологиями, за исключением
SSM и PI, которые не охватывают этот этап и, конечно, другие после168
дующие шаги. Физический дизайн рассматривается подробно всеми,
за исключением OOA, ISAC и ETHICS, которые менее ясны. ISAC
предлагает использование JSP на фазе дизайна данных.
Следующий этап, определенный как физический дизайн системы, характеризуется как программирование на рис. 3.3. Только STRADIS, IE и
JSD предусматривают программирование, при этом JSD рассматривает
это более подробно. Некоторые методологии предлагают или допускают
применение других подходов для физической разработки систем. ISAC,
например, рекомендует использование JSP и OOA, объектноориентированный язык, такой как Smalltalk. В таких случаях рекомендуемые средства не включены в состав методологий, охватывающих рассматриваемый этап. Тестирование, включающее в себя планирование
также как и испытание систем, программ и процедур, рассматривается
методологиями STRADIS, IE и JSD, но в подробностях только IE.
Внедрение, в котором осуществляется планирование и внедрение
технических, социальных и организационных аспектов, охватывается
IE, SSADM, Merise и ETHICS, хотя и не в таких больших подробностях как на предыдущих шагах, а также STRADIS и PI, но еще менее
подробно. JSD представляет собой особый случай, потому что ее интерпретация внедрения является просто технической и рассматривает
распределение процессоров между процессами. Оценка и анализ системы после ее внедрения связаны с измерением и оценкой внедренной системы и сравнением с начальными целями. Это рассматривается только STRADIS, IE, SSADM и ETHICS, при этом ETHICS, в частности концентрируется на оценке соответствия.
Завершающим этапом в анализе широты охвата является сопровождение, которое будем признавать как охваченное методологией, только
если оно специально рассматривается в терминах задач. Такой факт, как
упоминание в методологии того, что сопровождение может вообще быть
улучшено посредством ее использования на более ранних этапах, в данном анализе не признается как охват методологией этапа сопровождения. Используя это определение, можно определить, что только IE, Merise и ETHICS упоминают о сопровождении в каких-то подробностях.
169
Общая картина (рис. 3.3) демонстрирует, что основное внимание всех
представленных методологий концентрируется, в основном, на этапах
анализа и дизайна, но с вариациями в широком диапазоне, поэтому
утверждение, что все методологии одинаковы, является неверным.
Пятый элемент инфраструктуры касается производимых методологиями результатов. Оценка этой характеристики методологии требует проведения исследование того, что фактически создается в терминах выходов в конце каждого этапа методологии. Выходы методологий значительно отличаются и не только в смысле, что должно создаваться, но также в уровне подробностей, определяемых методологией. Такое большое расхождение в определении выходов тесно связано со степенью, в которой методология рассматривается как план
действий, т. е. насколько подробными являются правила о том, как
действовать и какие действия оставлены на усмотрение аналитика.
Связанный с выходами вопрос касается того, как и в какой мере
аналитики знают, что они действуют корректно. Например, ISAC
определяет в некоторых подробностях выходы этапа анализа перемен, но не описывает подробно процесс порождения альтернатив. Это
рассматривается как творческая часть методологии и не поддается
спецификации. Идентификация таких областей в методологии рассматривается как важный вклад в ее понимание.
Шестым элементом инфраструктуры сравнения является применение методологии. Он содержит подэлементы: истоки, количество
пользователей, приложения и участники. Основа методологии широко определяет ее происхождение: академическое или коммерческое.
STRADIS, YSM, IE, SSADM и OOA принадлежат к коммерческой
сфере, в то время как Merise, JSD, ISAC, ETHICS, SSM и PI имеют академическое происхождение, по крайней мере, отчасти, хотя это не
означает, что они сейчас не коммерческие методологии.
Возможно, это покажется удивительным, количество пользователей
является часто трудным для определения, а продукт, возможно, менее
распространенным, чем хотели бы нас уверить поставщики. Поставщики имеют привычку предполагать, что любая компания, проявившая
интерес к их методологии или купившая оценочную версию, являются
170
пользователями. Многие организации не используют брендовые методологии, они или все еще применяют традиционные подходы или свои
собственные внутренние вариации или подходы. По данным обзора
1990 г. во Франции Merise использовалась в разработках в 20–61% случаев, в Европе в целом 55% организаций использовали брендовые методологии разработки информационных систем.
Последний подэлемент характеристики «применение» требует проведения анализа участников. При этом требуется ответить на вопросы
«кто предположительно должен использовать методологию?» и «какие
роли они выполняют?». Он также пытается определить требуемый уровень квалификации. Традиционное представление разработки информационных систем состоит в том, что группа специалистов профессиональных системных аналитиков и дизайнеров выполняет аспекты анализа и дизайна, профессиональные программисты создают программы
и пишут коды. Система затем внедряется аналитиками. Этого общего
представления все еще придерживаются STRADIS, YSM, IE, SSADM,
Merise, JSD и OOA. Методологии SSM, ISAC, PI и ETHICS придерживаются другого представления, и их пользователям отводится намного
более активная роль. В ETHICS пользователи сами выполняют анализ и
дизайн, а профессионалы по обработке данных используются как консультанты, когда это требуется. В дополнение, ETHICS включает в состав роль посредника, задачей которого является руководство пользователями в использовании методологии. Посредники фактически сами
не выполняют задачи, но они совершенствуют процесс применения методологий разработки информационных систем и обеспечивают их
корректное выполнение. Посредник должен быть экспертом и обладать
опытом в использовании методологии.
Требуемой уровень квалификации для пользователей методологии
меняется значительно. Почти во всех методологиях, по крайней мере,
для части пользователей необходимо прохождение значительного
обучения и наличие опыта. Более того, многие предъявляют высокие
требования к пользователям, в этом случае методология, как можно
ожидать, должна включать в себя аспект обучения. Это может значительно увеличить время и стоимость, требуемую для разработки про171
екта. ETHICS, которая предъявляет высокие требования к пользователям, признает и рассматривает эти проблемы. Даже там, где методологии принимают на себя более традиционную роль, профессиональные аналитики и дизайнеры могут считать их на первых порах
довольно трудными для изучения, с их новыми словарями, способами
и средствами, необходимыми для работы с ними.
Завершающим элементом инфраструктуры для сравнения методологий является продукт. Он описывает то, что поставляется при приобретении методологии и по какой цене. Большинство методологий
имеют диапазон продуктов и осуществляемого обслуживания, которые могут быть выбраны или нет, хотя должен, вероятно, существовать минимальный набор. Продукт также, вероятно, должен часто
изменяться, в основном, благодаря увеличивающемуся количеству
поддерживающих средств. Продукт может колебаться от больших
наборов руководств, например, SSADM, до набора академических
статей и книги, как в случае SSM. Для некоторых методологий требуются консультанты, посредники и/или использование курсов обучения как части продукта. Некоторые методологии предлагают сертификацию компетенции для разработчиков. Существует, например,
сертификат схемы квалификации для SSADM.
Ключевые термины
Академическая методология
Домен методологии
Интеллектуальная основа
методологии
Коммерческая методология
Конечный продукт методологии
Область действия методологии
Парадигма науки
Парадигма систем
Прикладная область
методологии
Разрывы методологии
Целевой объект методологии
Цель методологии
Контрольные вопросы
1. В чем состоит отличие между методологией и методом?
2. Включает ли в себя методология спецификацию методов и
средств, которые должны использоваться?
172
3. Составляет ли набор методов и средств методологию?
4 .Каково приблизительное количество существующих сегодня в
мире методологий разработки информационных систем? Назовите
некоторые из них.
5. Должно ли использование методологии приводить каждый раз к
одному и тому же результату?
6. Дайте определение методологии.
7. Что должна рассматривать и определять методология?
8. Какие три ключевых компонента разработки информационных
систем выделяют сторонники методологий?
9. Назовите три основные категории причин, определяющих необходимость применения методологий.
10. Как методологии разработки информационных систем могут
улучшить конечный продукт?
11. Назовите 23 характеристики информационных систем, которые
могли бы быть использованы для оценки качества их разработки?
12. Как методологии разработки информационных систем могут
улучшить процесс разработки?
13. Назовите истоки происхождения методологии.
14. Какие три основные потребительских свойства коммерческих
методологий разработки информационных систем были существенно
улучшены в процессе эволюции методологий?
15. Определите роль академических методологий разработки информационных систем в процессе эволюции методологий?
16. Что может получить пользователь, приобретая методологию?
Оцените возможности приобретаемого в данном случае продукта по
семи параметрам.
17. Гарантируется ли поставщиками создание успешной информационной системы в результате использования распространяемой ими
методологии? Для любого ответа необходимо объяснить «почему?».
18. Назовите возможные критерии сравнения методологий и охарактеризуйте каждый из них.
19. Назовите и охарактеризуйте наиболее «полезные», с вашей
точки зрения, методологии разработки информационных систем.
Глава 4. ОСНОВНЫЕ ПРИНЦИПЫ РАЗРАБОТКИ
ИНФОРМАЦИОННЫХ СИСТЕМ
Как было установлено в разделе 2.1, если организация предполагает осуществлять разработку информационной системы, то желательно предварительно, руководствуясь основными принципами разработки, выбрать некоторый подход и наметить индивидуальный путь,
а также методы и средства CASE, которые она будет использовать,
продвигаясь по этому пути к намеченной цели. Хотя такой подход и
не гарантирует успешность разработки, но он, дисциплинируя процесс, существенно повышает вероятность успеха. То есть, организация должна определить, как конкретно она будет создавать систему,
выявляя последовательно по мере выполнения шагов разработки для
чего ей нужна система, из чего она будет состоять, как должны быть
взаимосвязаны ее компоненты и как это все вместе должно работать.
Этот процесс должен начинаться с разработки более общих моделей
отражающих вначале природу и действия предприятия, перерастая
затем в модели системы, затем в физические модели, учитывающие
специфику используемых технологических платформ, и, наконец,
плавно переходя в действующие программные коды системы.
Процесс разработки информационных систем не может полагаться
на авось. Информационные системы, также как и любой другой продукт, должны разрабатываться тщательно. Успешная разработка системы руководствуется некоторыми базовыми фундаментальными
принципами. Эта глава знакомит с основными принципами разработки информационных систем, основанными на подходах жизненного
цикла и данных. Основываясь на этих принципах, представляется
возможным осуществить сборку своей собственной методологии из
совокупности строительных блоков методологий разработки систем,
которые в системной последовательности рассматриваются в главах
5, 6 и 7. Как можно будет увидеть, вся совокупность этих блоков –
соответствующих им методов моделей и средств CASE, закрывает
практически полностью поле решений разработки, образованное
представлениями компонентов информационной системы. Процесс
174
их адаптации и привязки скорее должен быть выполнен не напрямую,
а опосредованно, через понимание смысла и выбора возможных модификаций или являющихся близкими аналогами рассмотренным
блокам. Руководствуясь этими принципами, в конце главы приводится также практический пример небольшой компании, который в
дальнейшем используется в последующих главах, рассматривающих
подробно эти строительные блоки методологий разработки информационных систем.
4.1. Жизненный цикл
и методологии разработки систем
Этот раздел является введением в процесс, используемый для разработки информационных систем. На практике его называют методологией. В теории все методологии выводятся из логического процесса
разработки, который, иногда, не совсем точно называют жизненным
циклом разработки систем.
Жизненный цикл разработки систем – это логический процесс, при
помощи которого системные аналитики, программисты и конечные
пользователи создают информационные системы и компьютерные
приложения для решения бизнес-задач и других потребностей. Он
иногда называется жизненным циклом разработки приложения. Жизненный цикл является по существу средством управления проектом,
используемым для планирования, выполнения и контроля проектов
разработки систем.
Методологии разработки систем часто путают с жизненным циклом разработки систем. Существует ли отличие? Некоторые эксперты
заявляют, что методологии заменили жизненный цикл. На самом деле, они являются почти одним и тем же. В общем смысле, цель жизненного цикла состоит в планировании, исполнении и контроле проекта разработки систем. Он определяет фазы и задачи, являющиеся
существенными для разработки системы, не зависимо от размера создаваемой системы. Обратим внимание на ударение на слове существенными. Например, мы всегда должны изучать и анализировать
175
текущую систему (на некотором уровне детализации) до определения
и ранжирования требований пользователей.
Упрощенно методология – это физическое воплощение логического жизненного цикла, включающее в себя следующее.
x Пошаговые процессы на каждой фазе/стадии.
x Индивидуальные и групповые роли, выполняемые в каждых процессах.
x Выходные результаты и стандарты качества на каждый процесс.
x Средства и методы, используемые в каждом процессе.
Необходимо отметить, что истинная методология должна охватывать полный жизненный цикл разработки систем. Во-вторых, большинство современных методологий включают в себя использование
ряд средств или методов разработки.
Почему компании используют методологии? Методологии гарантируют, применение совместимого воспроизводимого подхода ко
всем проектам. Методологии снижают риск, связанный с упрощениями и ошибками. В конечном счете, методологии обеспечивают полную и совместимую документацию от проекта к проекту. Все эти
преимущества также обеспечивают преемственность продолжения
работ при изменениях в составе персонала, передаче проекта другой
группе, а также при возобновлении работ после долгого перерыва.
Методологии могут быть и доморощенными (любительскими).
Однако некоторые предпочитают покупать методологии разработки.
Методологии предпочитают покупать, потому, что большинство организаций не могут позволить себе выделить персонал для сопровождения и непрерывного улучшения собственной методологии. К тому
же производители методологии имеют обоснованную заинтересованность в техническом сопровождении своих методологий в соответствии с последними тенденциями в бизнесе и технологиях.
Как можно заметить, в дальнейших разделах этой книге будет использованы строительные блоки методологий, основанные на некоторых методах и подходах и средствах, заимствованных из «лучшей
практики» существующих методологий.
176
4.2. Базовые принципы разработки систем
Принцип 1: Вовлечение собственников и пользователей. Аналитики, программисты и другие специалисты по информационным
технологиям часто ссылаются на «моя система». Эта позиция отчасти
порождена отношениям между техническим персоналом и их пользователями «мы – в сравнении – с ними». Не смотря на то, что аналитики
и программисты упорно работая, создают технологически впечатляющие решения, эти решения часто оборачиваются против них, потому,
что они не направлены на реальные проблемы организации или приводят к новым техническим или организационным проблемам. По этой
причине вовлечение владельцев и пользователей является абсолютно
необходимым для успешной разработки систем. Лица, ответственные за
разработку системы должны выделять свое время на владельцев и
пользователей, настаивать на их участии и добиваться соглашения с
ними по всем решениям, которые влияют на них.
Недопонимание и разногласия продолжают являться существенной проблемой в разработке систем. Однако участие владельцев и
пользователей и образование минимизируют подобные проблемы и
помогают достичь приемлемости новых идей и технических изменений. В силу того, что люди склонны противиться изменениям, компьютер очень часто рассматривается как угроза. При помощи образования информационные системы и компьютеры могут по существу
рассматриваться пользователями как средства, которые сделают их
работу приятной и необычной.
Принцип 2: Использование подхода решения проблем. Методология является, прежде всего, подходом решения проблем для построения систем. Термин проблема используется в данном контексте,
чтобы включить реальные проблемы, возможности для улучшения, и
директивы от менеджеров. Классический подход решения проблем
состоит в следующем.
x Изучение и понимание проблемы (возможности и/или директивы) и ее системный контекст.
x Определение требований для подходящего решения.
177
x Определение вариантов решения и выбор лучшего решения.
x Разработка и применение решения.
x Осознание, оценка значения решения и улучшение решения.
Это означает, что системный аналитик должен рассматривать весь
проект, используя некоторый вид подхода решения проблем.
Среди разработчиков, неопытных в решении проблем, существует
тенденция устранения или сокращения одного или более из указанных
выше этапов. Результат может варьироваться от (1) решения ошибочной проблемы, (2) ошибочно решенной проблемы, (3) выбора неправильного решения. Проблемная ориентация методологии при правильном применении может снизить или устранить вышеуказанные риски.
Принцип 3: Установление стадий и процессов. Большинство жизненных циклов и методологий представляют процесс разработки в виде
этапов или стадий. В своей простейшей классической форме жизненный цикл состоит из четырех фаз: планирование систем, анализа, проектирование системы и внедрения системы. (Пятый процесс, поддержка/сопровождение системы, усовершенствует полученную систему путем итеративного перебора предыдущих четырех этапов в меньшем
масштабе времени и объема работ, чтобы улучшать и усовершенствовать систему в ходе ее эксплуатации.) В свою очередь фаза анализа может быть представлена в виде двух последовательных фаз – анализ требований и спецификация/структурирование требований для выделения
в отдельные смысловые блоки процессов, связанных с бизнес-объектом
и системой.
Рис. 4.1 иллюстрирует этапы разработки информационной системы
в контексте фреймворка архитектуры информационной системы (см.
раздел 1.3). На каждом этапе аналитики и участники определяют и/или
разрабатывают строительные блоки системы, соответствующие этапу
строки фреймворка. Строительными блоками в данном случае являются «данные», «функции/процессы», «люди» и «интерфейсы». Следует
обратить внимание, что по мере продвижения сверху вниз по стадиям,
мы продвигаемся все ближе к технической базе пирамиды, предполагая, что наши ранние касания относятся к бизнесу, а последующие становятся все более зависимыми от технологий.
178
Функциональные
модели
Клиент
Авто транспорт
Подавать
Участники
деятельности
Контекст
Организационная
схема
Планирование
системы
Контекстная схема
Диалоги и
интерфейс
Персонал –
функции
Проходить
Директор
Заказ
Техническое обслуживание
Заключить
Расходы ГМ
Z
Z
По луприцеп
Договор
Тягач
Начальник цеха
Бухгплтер
Мастер
Менеджер по управлению
отношениями с клиентами
Заправляться
Закрепить полуприцеп
Перевезти из
Закрепить тягач
Пекарь 5
Пекарь 4
Пекарь 6
Бригада
доставки 3
Бригада
доставки 2
Архитектура интерфейса персонала
Интерфейсы
системы
Интерфейс
мастера
Физическая
схема
Физическая
модель
процессов
Интерфейс CRM
менеджера
Интерфейс
экспедитора
Потоки
диалогов
Меню производственной бригады
Получение сырья
Добавление сырья
Подтверждение добавления
Подтверждение получения
Оформление накладной на перемещение
Формирование лота доставки
Добавление лота доставки
Добавление изделия
Подтверждение добавления
Удаление изделия
Подтверждение удаления
Завершение формирования лота доставки
Подтверждение завершения формирования лота
Передача продукции на склад
Добавление лота доставки
Подтверждение добавления
Подтверждение окончания передачи
Оформление накладной на перемещение
Интерфейс
производственной
бригады
Экранные
формы,
отчеты
Диалоги
0
Экран
Log In
Система
1
Главное меню
0, Система
2
3
Получение
сырья
Формирование
лота доставки
1
4
Передача
продукции на
склад
1
2.1
2.2
3.1
Добавление
сырья
Подтверждение
получения
сырья
Добавление
лота доставки
1
4.1
4.1.1
Добавление
лота доставки
Подтверждение
добавления
4
2
3
2.2.1
3.1.1
3.1.2
3.1.3
Подтверждение
добавления
Оформление
накладной на
перемещение
сырья
Добавление
продукта
Удаление
продукта
Завершение
формирования
лота
доставки
2.1
2.2
3.1
3.1
CREATE TABLE Заказчик
(Customer_Code decimal(6) NOT NULL,
Customer_Name CHAR(18) NOT NULL,
Castomer_Data CHAR(18) NOT NULL);
CREATE TRIGGER tI_Заказ AFTER INSERT ON Заказ
REFERENCING NEW AS NEW FOR EACH ROW MODE DB2SQL
WHEN (((SELECT count(*) FROM Заказчик WHERE
new.Customer_Code = Заказчик.Customer_Code) = 0))
SIGNAL SQLSTATE '75001' ('Cannot insert Заказ because
Заказчик does not exist.') !!
CREATE TRIGGER tU_Заказчик NO CASCADE BEFORE UPDATE ON
Заказчик
REFERENCING OLD AS OLD NEW AS NEW FOR EACH ROW
MODE DB2SQL
WHEN (((SELECT count(*) FROM Заказчик WHERE
Заказчик.Customer_Code <> :new.Customer_Code) > 0) AND
((SELECT count(*) FROM Заказ WHERE Заказ.Customer_Code =
old.Customer_Code) > 0))
SIGNAL SQLSTATE '75001' ('Cannot update Заказчик because
Заказ exists.') !!
Технология
баз данных
Прикладные программы
Процедуры
3.1.2.1
3.1.3.1
Подтверждение
удаления
Подтверждение
завершения
формирования
лота
3.1.2
3.1.3
4.2.1
4.2
Оформление
накладной на
перемещение
товара
Подтверждение
окончания
передачи
4.2
4
Программы
компонент
DO CASE
CASE v9 = 1
show get nMove disable
show get v3 disable
show get v4 disable
show get v2 enable
select max(организа.код);
from организа;
into array m
IF _TALLY <> 0
f1=m(1)+1
ELSE
f1=1
ENDIF
f2=" "
f3=VAL(" ")
f4=" "
f5=" "
f6=VAL(" ")
DO CASE
CASE nMove = 1
GO TOP
CASE nMove = 2
SKIP -1
IF BOF()
GO TOP
ENDIF
CASE nMove = 3
SKIP
IF EOF()
GO BOTTOM
ENDIF
CASE nMove = 4
GO BOTTOM
ENDCASE
SHOW GETS
для кнопки “Удалить”
delete for код=f1
pack
f1=VAL(" ")
f2=" "
f3=VAL(" ")
f4=" "
f6=VAL(" ")
show gets
для кнопки “Изменить”
delete for код=f1
pack
insert into организа.dbf;
values (f1,f2,f3,f4,f5,f6,f7)
select *;
from организа g;
into array q;
where g.код=f1
f1=VAL(" ")
f2=" "
f3=VAL(" ")
f4=" "
Программные
и аппаратные
технологии
3.1
3.1.1.1
Подтверждение
добавления
3.1.1
CREATE TABLE Заказ
(Order_Num decimal(10) NOT NULL,
Receive_Data DATE NOT NULL,
Customer_Code decimal(6) NOT NULL,
Status_Code CHAR(18) NOT NULL);
4.1
2
2.1.1
Внедрение
системы
Модели
процессов
Пекарь 3
Пекарькондитер 1
Технологии
управления
Технология
интерфейсов
Поддержка
и сопровождение
системы
Логическая
схема
Пекарькондитер 2
Водитель 3
Z
Водитель 2
Водитель
Путевой лист
Экспедитор 3
Транс по ртная накладная
Экспедитор 2
Исполнить
Z
Z
Грузчик
Быть напарником
Перевезти груз
Счет
Водитель 1
Оплатить
Двигаться в
Бригада
доставки 1
Z Задание экипажу
Двигаться из
Элементарный путь
Экспидитор 1
Нас еленные пункты
Возглавлять
Производствен
ная бригада 3
Ночная смена
Выдать задание
Производствен
ная бригада 2
Ночная смена
Экипаж
Перевезти в
Производствен
ная бригада 1
Дневная смена
Владельцы системы
Конструкторы Пользователи
системы
системы
Дизайнеры
системы
Функции
Коды SQL
Создатели
системы
СИСТЕМНЫЕ АНАЛИТИКИ (АРХИТЕКТОРЫ)
Объекты
деятельности
Люди
Проектирование
Спецификация Анализ требо(дизайн)
требований
ваний
системы
Функции/
процессы
Данные
Разработка
системы
Рис. 4.1. Классические фазы разработки системы
179
Так как проекты могут быть довольно большими, и каждый этап
обычно представляет значительную работу и время, этапы, как правило, разбиваются на действия и задачи, которые могут быть более
легко управляемыми и которые могут дать на выходе конкретный полезный результат. В этой главе внимание будет сосредотачиваться
только на этапах, хотя и несколько более совершенных, чем показано
на рис. 4.1. Виды действий и задач, лежащие в основе этапов, будут
рассмотрены в последующих главах.
Как правило, фазы проекта должны завершаться в последовательности сверху вниз. Это может создать впечатление, что как только мы
выполним очередной этап, так мы его и завершили. Однако это не
так. В любой момент времени, мы можем выполнять задачи более
чем одной фазы одновременно. Иногда, возможно, придется возвратиться к предыдущим этапам и процессам для внесения исправлений
или реагирования на новые требования. Очевидно, что мы не можем
увлечься выполнение таких типов отката, иначе нам, возможно, никогда не внедрить новую систему.
Принцип 4: Установление стандартов для совместимости
разработок и документации. Организация имеет много информационных систем, которые могут включать в себя тысячи программ
и пакетов программного обеспечения. Если бы все аналитики и
программисты использовали свою методологию по своему предпочтению, свои собственные инструменты и методы для разработки
систем документооборота, то это бы быстро привело к хаосу.
В средних и крупных подразделениях информационных систем повсеместно среди системных аналитиков, программистов и технических специалистов наблюдается текучесть кадров. Это же происходит среди собственников системы и ее пользователей. Для поддержки эффективной связи между этой постоянно меняющейся базой пользователей и профессионалов в области информационных
систем необходимо разработать стандарты по обеспечению совместимости разработки систем.
Стандарты разработки систем обычно описывают (1) деятельность,
(2) обязанности, (3) рекомендации или требования по документиро180
ванию, и (4) контроль качества. Эти четыре стандарты должны быть
установлены для каждого этапа в методологии.
Потребность в стандартах на документацию подчеркивает общую
несостоятельность многих аналитиков – неспособность к документированию в качестве текущей деятельности в течение жизненного цикла.
Большинство студентов и специалистов практиков говорят о важности
документации, но говорить легко. Когда мы действительно размещаем
комментарии в наших компьютерных программах? После того как мы
закончим, конечно. В этом и заключается проблема. Большинство из
нас, как правило, размещают комментарии после завершения разработки программы. К сожалению, мы часто являемся носителями этой плохой привычки, разрабатывая информационные системы.
Документация должна быть рабочим побочным продуктом всех
усилий по разработке системы. Документация показывает сильные и
слабые стороны системы другим лицам до того как будет построена
система. Она стимулирует вовлечение пользователей и информирует
руководство о прогрессе хода работ.
Принцип 5: Причисление системы к капитальным вложениям.
Информационные системы являются капитальными вложениями, так
же, как парк грузовиков или новое здание. Даже если руководство не
признает систему в качестве инвестиций, мы не должны этого делать.
При рассмотрении капитальных вложений должны быть решены два
вопроса. Во-первых, для решения какой-либо проблемы, скорее всего, будет несколько возможных решений. Аналитик не должен принимать первое решение, которое приходит ему на ум. Аналитик, который не рассмотрел несколько альтернатив, является любителем.
Во-вторых, после определения альтернативных решений системный
аналитик должен оценить каждое из них на осуществимость/целесообразность и, особенно, экономическую эффективность.
Экономическая эффективность определяется как результат, полученный в результате проведения сопоставления стоимости разработки и эксплуатации системы c выгодами, полученными от системы.
Анализ выгодности или целесообразности затрат является важным
навыком для освоения аналитиком.
181
Принцип 6: Не бояться отмены или пересмотра масштаба проекта. Существенным преимуществом поэтапного подхода к разработке систем является то, что он предоставляет несколько возможностей пересмотреть целесообразность. Часто существует искушение
продолжать проект только потому, что инвестиции уже сделаны.
В долгосрочной перспективе, аннулирование проектов являются менее дорогостоящими, чем реализованные бедствия. Это чрезвычайно
важно помнить молодым аналитикам.
Кроме того, многие аналитики позволяют разрастаться масштабу
проекта во время его выполнения. Иногда это неизбежно, потому что
аналитик узнает больше о системе по мере развития проекта. К сожалению, большинство аналитиков не выполняют своей обязанности
выверки расчетных затрат и календарных графиков работ при расширении масштаба. В результате, аналитик часто и напрасно принимает
на себя ответственность за превышение затрат и нарушение календарного графика работ.
Существуют сторонники подхода возрастающего (приростного)
обязательства. При использовании подхода возрастающего обязательства в методологии разработки систем встраивается несколько
точек проверка осуществимости/целесообразности. В любой точке
проверки осуществимости все расходы считаются невозвратными
издержками (то есть невосстанавливаемыми). Таким образом, проект должен быть переоценен в каждой контрольной точке, чтобы
определить, является ли он все еще осуществимым/целесообразным.
В каждой контрольной точке, аналитик должен рассмотреть (1) отмену проекта, если он уже нецелесообразен, (2) переоценку затрат и календарного графика, если масштаб проекта должен быть увеличен, или (3)
сокращение масштаба, если бюджет проекта и календарный график заморожены, и не достаточны, чтобы покрыть все цели проекта.
Понятие невозвратных издержек является более или менее знакомым некоторым финансовым аналитикам и менеджерам, но часто забываемым или не используемым большинством практикующих аналитиков и пользователей.
182
Принцип 7: Разделяй и властвуй. Все системы являются частью
более крупных систем (так называемых суперсистем или надсистем).
Подобно этому, существующие системы включают в себя меньшие
системы (так называемые подсистемы). Эти факты имеют значение
по двум причинам. Во-первых, системные аналитики должны иметь в
виду, что любая система, над которой они работают, взаимодействует
со своей суперсистемой. Если суперсистема постоянно меняется, то,
возможно, меняется масштаб любого данного проекта. Большинство
системных аналитиков все еще можно обвинить в недооценке размера проектов. Большая часть вины связана с неточным изучением участия данной системы в ее боле большом целом, ее суперсистеме.
Существует старая поговорка: «Если вы хотите узнать что-нибудь,
вы не должны пытаться узнать все, по крайней мере, не все сразу».
По этой причине, мы разделяем систему на ее подсистемы для того,
чтобы легче преодолеть проблему и построить большую систему.
Разделив более большую проблему (систему) на более легко управляемые части (подсистемы), аналитик может упростить процесс решения проблемы. Мы будем применять этот принцип в дальнейшем.
Принцип 8: Проектирование систем для роста и перемен. Существует острая нехватка специалистов в области информационных
систем, необходимых для разработки. В сочетании с постоянно растущим спросом на разработку систем многие системные аналитики
попали в ловушку разработки систем для удовлетворения только сегодняшних потребностей пользователей. Хотя это может показаться
необходимым подходом на первый взгляд, это на самом деле оборачивается против разработчиков почти во всех случаях.
Энтропия является термином, используемым ученым по системам
для описания естественного и неизбежного распада всех систем. Энтропия в контексте жизненного цикла разработки систем показана на
рисунке 4.2. После того как система внедрена она вступает в фазу
жизненного цикла «поддержка и сопровождение». Во время фазы
поддержки, аналитик сталкивается с необходимостью внесения изменений, которые варьируются от корректировки простых ошибок, до
повторного проектирования системы для приспособления изменяю183
щейся технологии и внесения изменений в соответствии с изменяющимися требованиями пользователей. Как показывают пунктирные
стрелки, многие из этих изменений побуждают аналитика и программиста переработать предыдущие этапы жизненного цикла. В конце
концов, стоимость обслуживания превышает затраты на разработку
системы с самого начала, – система изжила себя. Это показано на рисунке сплошной линией со стрелкой.
Рис. 4.2. Сопровождение системы и энтропия
Часто, системы, которые были разработаны в соответствии только
с текущими требованиями предприятия, являются трудными для усовершенствования в ответ на изменившиеся новые требования. Системный аналитик часто вынужден дублировать файлы и программы
«patch», что делает систему очень дорогой в длительном обслуживании.
В результате многие аналитики систем разочаровываются в том большом количестве времени, которое должно быть посвящено поддержке
существующих систем (их часто называют устаревшими), и как мало
времени осталось для работы над важной новой разработкой.
Даже если вы проектируете систему, легко адаптируемую к изменениям (последний рассмотренный принцип), то в какой-то момент
станет слишком дорого, чтобы просто поддерживать существующую
184
систему. Почему? Возможно, организация сама изменилась слишком
резко, чтобы быть поддерживается системой. Или, возможно, требования стали слишком сложны, чтобы они могли быть интегрированы
в текущую систему. В любом случае это время, чтобы начать заново.
Эта ситуация переводит термин цикл в жизненный цикл разработки
систем. Ни одна система не существует вечно (хотя многие из них
длятся на протяжении десяти лет и более).
Но энтропия системы может быть управляемой. Современные средства и методы делают возможным разработку систем, которые могут
расти и изменяться, по мере роста и изменения требований. Эта книга
научит многим из этих инструментов и методов. На данный момент,
более важно, просто признать, что гибкость и адаптируемость не возникают случайно – они должны быть встроены в систему.
1. Вовлечение собственников и пользователей
2. Использование подхода решения проблем
3. Установление стадий и процессов
4. Установление стандартов для совместимости разработок
и документации
5. Причисление системы к капитальным вложениям
6. Не бояться отмены или пересмотра масштаба системы
7. Разделяй и властвуй
8. Проектирование систем для роста и перемен
Рис. 4.3. Принципы разработки систем
Таким образом, мы представили восемь принципов, которые
должны лежать в основе любой методологии. Эти принципы, кратко
обобщенные на рис. 4.3, могут быть использованы для любой методологии.
4.3. Практический пример предприятия
В данном разделе рассматривается пример предприятия, которое
условно назовем «Свежая выпечка». Пример будет использоваться
нами в дальнейших разделах при изучении рассматриваемых методов.
185
Содержание и структуризация излагаемых сведений о предприятии ведется в соответствии с выделенными нами в настоящей главе
строительными блоками фреймворка архитектуры информационной
системы, включающие в себя «данные», «функции/процессы», «люди». Описание дает представление на самом верхнем уровне инфраструктуры архитектуры, соответствующем части этапа планирования, изучающему текущее состоянию предприятия, то есть состоянию «как есть» или «as is». Такие сведения можно получить в результате обследования существующего предприятия, что обычно и
выполняется разработчиками систем на начальном этапе жизненного цикла.
Малое предприятие «Свежая выпечка» специализируется на выпуске и реализации хлебопекарной продукции. Оно располагает технологической линией, автотранспортом, закупает и использует сырье,
принимает заказы, производит продукцию, доставляет ее в точки розничной торговли, осуществляет расчеты с поставщиками и клиентами, а также осуществляет самостоятельную розничную реализацию
продукции на месте ее производства.
Организационная структура. Производство, доставку продукции, а также управление осуществляет персонал предприятия, организованный, как это показано на рис. 4.4.
Технологическое оборудование, оснастка, помещения, используемые в производстве, хранении и доставке продукции предприятием, приведены в табл. 4.1.
Выпускаемая продукция. Предприятие выпускает продукцию,
примерный перечень которой приведен в табл.4.2.
Используемое сырье. Для выпуска продукции предприятие использует сырье, состав которого приведен в табл. 4.3.
Категории лиц, имеющих отношение к предприятию. Определения этих категорий лиц, как физических, так и юридических, имеющих отношение к деятельности предприятия приведено в табл. 4.4.
186
Директор
Начальник цеха
Бухгплтер
Бригада
доставки 3
Бригада
доставки 2
Бригада
доставки 1
Грузчик
Производствен
ная бригада 3
Ночная смена
Производствен
ная бригада 2
Ночная смена
Производствен
ная бригада 1
Дневная смена
Мастер
Пекарькондитер 2
Пекарь 3
Пекарь 5
Водитель 1
Водитель 2
Водитель 3
Пекарькондитер 1
Пекарь 4
Пекарь 6
Экспидитор
1
Экспедитор
2
Экспедитор
3
Рис. 4.4. Персонал и его организация
Таблица 4.1
Технологическое оборудование и оснастка
тип объекта
оборудование
печь хлебопекарная
тестомесильная
машина
машина взбивальная
тестозакаточная
машина
морозильный ларь
мукопросеиватель
шкаф расстойный
описание
совокупность устройств, обеспечивающих
работу предприятия
устройство для выпечки изделий из теста
устройство для замеса теста из сырья и его
выдержки
устройство для взбивания мягкого теста,
сливок, крема, мусса и т. п
машина для придания тестовым заготовкам
цилиндрической формы
устройство для хранения скоропортящейся
продукции
устройство для рыхления и отделения посторонних примесей
устройство для контролируемого брожения
теста перед выпечкой
187
Окончание табл. 4.1
технологическая
оснастка
протвени (подовые листы), формы
для выпечки, шприцы и т. п.
крытые грузовые автомобили малой
транспортные средства грузоподъемности, приспособленные для
перевоза продукции помещенной в лотки
лотки установленного размера и формы,
транспортировочная
имеющие определенную вместимость
тара
для каждого товара
специальное помещение или определенное место
для размещения и хранения сырья, упаковки и
склады
готовой продукции. различают склад сырья и
материалов и склад готовой продукции
Таблица 4.2
Примерный перечень выпускаемой продукции
Наименование продукции
«Гамбургер»
«Гата»
«Лаваш»
«Пицца»
«Слоеный рогалик со сгущенкой»
Расфасовка
1/130
1/200
1/500
1/150
1/200
Цена (руб.)
19
22
15
19
22
Таблица 4.3
Примерный состав используемого сырья
Мука
Сахар
Гвоздика
Сода
Яйцо
Дрожь
Мед
Уксус
Мак
Сахарная пудра
Соль
Помидоры
Огурцы
Капуста
Сосиски
Лук
Перец
Сыр
Кетчуп
Майонез
Сгущенное молоко вареное/
термостабильное
Лимонная кислота
Маргарин столово-молочный
Маргарин домашний
Сгущенное молоко вареное
Пищевые красители
Растительное масло
Украшения для тортов
Контейнеры для тортов 1, 2, 3 кг
Контейнеры для тортов 0,3, 0,4, 0,5 кг
188
Таблица 4.4
Категории лиц, имеющих отношение
к деятельности предприятия
Наименование
Описание
Работники
Лица связанные, с предприятием договором найма
Поставщики
Предприятия, осуществляющие поставку
сырья и материалов
Клиенты
Предприятия розничной торговли, заказывающие
и принимающие продукцию предприятия
для реализации
Владельцы
Лица, обладающие правом собственности
на предприятие
Управленческие и технологические документы. В процессе
своей деятельности, предприятие самостоятельно разрабатывает или
приобретает готовые формы управленческих документов, новую продукцию и технологию ее производства, а также вводит требуемые абстрактные понятия и их термины, необходимые для ведения и организации работ (табл. 4.5.)
Функции предприятия. Функционирование предприятия может
быть изображено при помощи модели функциональной декомпозиции, как это представлено на рис. 4.5.
Организация и проведение работ. Предприятие осуществляет закупку сырья и упаковки у своих поставщиков. Определение потребности производится начальником цеха на основании опыта, сложившегося спроса на продукцию компании, учета остатков сырья на
складе и норм расхода, определяемых рецептурой. Заявка с данными
о потребности передается поставщикам, которые поставляют сырье в
соответствии с установленными сроками. Поступившее сырье принимается и помещается на склад сырья. Компания ведет учет его поступления и расхода. Данные о поступившем сырье записываются в
специальный журнал. Все операции выполняет начальник цеха. Он
же отвечает за сохранность сырья на складе.
189
Таблица 4.5
Управленческие и технологические документы
Наименование
Маршрут доставки
Задание на смену
Счет-фактура
План доставки продукции
Рецептура
Описание
Путь следования транспортного средства с
продукцией и прилегающие к данному пути точки розничной торговли, являющиеся
клиентами предприятия
Документ, определяющий виды продукции
и ее количество, которое необходимо произвести за смену
Документ, подтверждающий факт передачи продукции продавцом покупателю и
определяющий состав, количество переданной продукции, ее стоимость и дату передачи
Документ, определяющий состав и количество товара, загружаемого в каждое транспортное средство на каждый рейс, отправляемый по определенному маршруту
Сведения о качественном и количественном составе компонент, а также о последовательности операций, необходимых для
изготовления определенного количества
некоторого вида продукции
Производство продукции осуществляется на основе сменных заданий. Задания подготавливаются на основе опыта и сложившегося
спроса на продукцию компании. Расчет потребности в необходимом
сырье ведется ручным способом. Подготовку сменных заданий и расчет потребности в сырье осуществляет начальник цеха. Им же осуществляется выдача сырья со склада мастеру и передача сменного задания мастеру. Мастер обеспечивает управление и контроль производственного процесса, который направлен на выполнение сменного
задания. Производство продукции осуществляется тремя бригадами.
Первая бригада работает ежедневно в дневное время в период с 8-00
до 17-00. Она, в основном, занимается производством более сложной
продукции (торты, пирожные, гамбургеры и т.п.). В ночное время
производство осуществляется второй и третьей бригадами, которые
190
работают поочередно через двое суток с 20-00 до 8-00. Ночные бригады, в основном, осуществляют выпуск более простой, хлебопекарной продукции. Планирование расстановки бригад, последовательности изготовления продукции и табельный учет работников бригад
осуществляется мастером.
Функционирование
предприятия
Передача
продукции
Перевозка
Реализация продукции
с доставкой
Отпуск/
Погрузка
партии
Формирование
маршрутов,
партий
Передача на
склад ГП
Упаковка/
Заполнение
тары
Реализация
продукции на месте
Изготовление
Получение
сырья
Полученние
сырья
Размещение
заявки
Определение
потребности
Определение
объема
выпуска
Призводство
продукции
Закупка сырья
Рис. 4.5. Функциональная декомпозиция деятельности предприятия
В процессе производства работники бригад используют сырье,
оборудование, оснастку и рецептуру. Модель движения материалов и
полуфабрикатов в производственном процессе представлена на рис.
4.6. Технологический процесс производства продукции включает в
себя следующие подпроцессы:
x Подготовка муки при помощи мукопросеивающей машины.
x Подготовка смеси для изготовления теста, которая размещается
в емкости, называемой дежа.
x Подготовка теста при помощи тестомесильной машины.
x Подготовка тестовых цилиндрических заготовок при помощи тестозакатачной машины и далее из них шарообразных заготовок вручную.
x Подготовка наполнителей, начинки, кремов.
x Расстойка (процесс контролируемого брожения) шарикообразных заготовок в расстойном шкафу.
x Изготовление изделий-полуфабрикатов, расстойка невыпеченных изделий в расстойном шкафу.
191
Упакованная
продукция
Рабочие столы
Транспортировочные лотки
Порции
теста
Выпеченная
продукция
Печи хлебопекарные
Тестомеситель
Дежа
Мукопросеиватель
Разделочный стол
Разрыхленные
Сырые изделия
заготовки
Разрыхленные
изделия
Тестомеситель
Стелажная тележка
Заготовки
шарики
Стелажная тележка
Шкаф расстойный
Рис. 4.6. Движения материалов и полуфабрикатов в технологическом процессе производства продукции
x Размещение невыпеченных полуфабрикатов на подовых листах. Печь имеет несколько камер, в каждой камере может быть размещено несколько подовых листов.
x Выпечка изделий в хлебопекарной печи.
x Выемка испеченных изделий из печи, остывание, выемка изделий из форм (для булочек) и декорирование.
Изготовленные изделия в зависимости от их вида подлежат упаковке и сборке в лотки (например, булочки по 50 шт. на один лоток).
Затем продукция передается на склад готовой продукции, где она
принимается от мастера начальником цеха. При приеме-передаче
данные о поступившей на склад продукции регистрируются в журнале прихода склада. Учет продукции ведется поштучно.
Реализация продукции на месте осуществляется мастером. При
этом оформляется счет-фактура, осуществляется запись в журнале
продаж, принимается выручка (возможен отпуск товара в кредит).
Мастер отчитывается за реализованную продукцию перед начальником цеха.
Доставка и реализация продукции розничным продавцам торговых
точек осуществляется тремя бригадами доставки, в состав которых
входят экспедитор и водитель. Доставка осуществляется специально
оборудованными транспортными средствами. Доставка ведется по
заранее определенным маршрутам, к которым прилегают торговые
точки клиентов. Доставка осуществляется в дневное время в период с
8-00 до 17-00. На предприятии принят следующий порядок выполнения этой функции. Начальник цеха заблаговременно (с вечера предыдущего дня) планирует состав и количество продукции в каждой доставляемой партии товара, распределяет партии по маршрутам, закрепляет транспортные средства по маршрутам. Он также распределяет работников по бригадам и бригады – по транспортным средствам. Все это отражается в плане доставки продукции. Начиная с
начала рабочего дня, осуществляется выполнение этого планы. В отпуске, приемке и погрузке продукции на транспортное средство
193
участвуют: начальник цеха, экспедитор и грузчик. При этом делаются
соответствующие записи в журнале выдачи готовой продукции со
склада. Товар доставляется в торговые точки в последовательности,
определяемой их географическим расположением относительно
маршрута. Отпуск товара в торговых точках осуществляется по потребностям покупателя. При отпуске товара оформляется счетфактура и принимается выручка. Неудовлетворенная потребность
клиентов фиксируется и учитывается при формировании следующих
партий товара (возможен отпуск товара в кредит). При возвращении
транспортного средства на предприятие производится передача копий счет-фактур на доставленный товар и выручки начальнику цеха,
а также возврат транспортировочной тары.
Ключевые термины
Адаптируемость системы
Анализ выгодности и целесообразности затрат
Гибкость системы
Динамика проекта
Жизненный цикл
Контрольные точки переоценки
проекта
Методология
Пользователи системы
Приростное обязательство
Проблема
Процессы разработки
Риски неправильного решения
проблем
Собственники системы
Стадии разработки
Стандарты разработки
Строительные блоки системы
Существующая система
Энтропия
Контрольные вопросы
1. В чем состоит различие между жизненным циклом разработки
систем и методологией?
2. Почему компании используют методологии?
194
3. Какие существуют восемь принципов разработки систем? Объясните, что вы могли бы встроить эти принципы в процесс разработки систем?
4. Что такое энтропия и как она влияет на разработку системы?
5. Почему для успешной разработки систем требуется вовлечение
владельцев и пользователей в процесс разработки?
6. К каким последствиям может привести игнорирование одного
или нескольких этапов подхода решения проблем при разработке системы?
7. Назовите четыре классические фазы разработки системы.
8. Назовите основные строительные блоки системы.
9. Что описывают стандарты разработки систем?
10. Какие два вопроса должен решить аналитик при рассмотрении
капитальных вложений?
11. В чем состоит подход приростного обязательства?
12. Объясните принцип «разделяй и властвуй».
Глава 5. ПЛАНИРОВАНИЕ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
Современные информационные системы полностью охватывают
предприятие. Не интегрированные системы, используемые в прошлом и называемые сегодня «островками информации», замещаются
интегрированными системами предприятий. Решение задачи наведения мостов между этими островками в организациях требует некоторого времени и это представляет ясное направление для развития информационных систем.
Получение интегрированной системы масштаба всего предприятия
вызывает существенные трудности для корпоративного менеджмента
и менеджмента информационной системы. Разумная идентификация
и выбор проектов информационных систем для новой или замещаемой системы является важным шагом в получении контроля над системами и данными.
Приобретение, разработка и сопровождение информационных систем требует существенных затрат ресурсов для большинства организаций. Это наводит на мысль, что организация может получить выгоду от следования по пути формально определенного процесса идентификации и выбора проектов.
5.1. Идентификация и выбор проектов разработки систем
Начало разработки информационной системы связано с идентификацией и выбором проектов. На этом этапе работ назначенное должностное лицо или сформированная группа или комиссия определяют
и оценивают возможные проекты разработки, которые могла бы выполнить организация. Далее проекты, которые предположительно
способны принести существенную выгоду организации, выбираются
для последующей разработки и соответственно обеспечиваются необходимыми для этого ресурсами. Способ выполнения этого этапа и
организация работ могут сильно изменяться в зависимости от размера
196
организации, значимости будущих изменений, источника финансирования и т.п.
Существует множество источников, из которых могут поступать
запросы или предложения на разработку информационных систем.
Одним из них могут быть менеджеры или подразделение организации, подающие запрос на замещение или расширение существующей
системы для получения необходимой информации или обеспечения
нового вида обслуживания клиентов. Другим источником могут быть
менеджеры информационной системы, желающие повысить результативность системы и снизить эксплуатационные расходы или заменить существующую операционную среду более совершенной. Последним из источников проектов является официально назначенная
группа планирования, которая определяет проекты для будущего
улучшения, способствующего достижению организацией ее корпоративных целей (например, создание системы улучшающей обслуживание заказчиков). Вне зависимости от того, каким образом данная организация фактически выполняет процесс идентификации и выбора,
существует общая последовательность выполняемых действий.
5.1.1. Процесс идентификации и выбора проектов разработки
информационных систем
Рассматриваемый процесс состоит из трех видов элементарных
действий:
x идентификация потенциальных проектов разработки;
x классификация и ранжирование проектов;
x выбор проектов для разработки.
Каждый из этих шагов может быть определен следующим образом.
Идентификация потенциальных проектов разработки. Этот
процесс в различных организациях может осуществляться различными способами. Он может выполняться следующими исполнителями:
197
x ключевыми фигурами высшего менеджмента, или исполнительным директором в организациях малой и средней величины или одним из исполнительных директоров в большой организации;
x подготовительной комиссией, состоящей из менеджеров подразделений, заинтересованных в системах;
x подразделениями пользователей, применяющих системы, в которых руководитель или комиссия подразделения принимает решение о выборе проектов на рассмотрение;
x группой разработки или менеджером информационной системы.
Все эти методы идентификации имеют сильные и слабые стороны.
Выполненные исследования показали, что, например, проекты, идентифицированные высшим руководством, более часто имеют стратегический организационный акцент. Альтернативно, проекты, идентифицированные подготовительными комиссиями, как правило, отражают многообразие областей деятельности организации, определяемое составом комиссии, и, следовательно, имеют многофункциональный акцент. Проекты, идентифицированные отдельными подразделениями, очень часто отличаются узким, тактическим подходом. Основной характеристикой проектов, идентифицированных группой
разработки, является облегчение интеграции предложенного проекта
с существующими средствами. Другие положительные факторы этого
источника проектов проявляются в стоимости проекта, продолжительности, сложности и рисках.
Из всех возможных источников, проекты, идентифицированные
высшим менеджментом и подготовительной комиссией, наиболее часто отражают широкие потребности организации. Это происходит
потому, что эта категория лиц обладает более широким пониманием
глобальных целей и ограничений для предприятия. Поэтому такие
проекты можно охарактеризовать как поступающие из нисходящих
источников.
Проекты, идентифицированные функциональным менеджером или
подразделением или группой разработки информационных систем,
198
часто направлены на конкретные потребности внутри подразделения
организации. Они не могут отражать глобальные цели организации.
Это не означает, что такие проекты неполноценны, только потому,
что они могут не рассматривать более широко вопросы организации.
Эти проекты часто характеризуют как поступившие из восходящих
источников. В проектах такого типа обычно начинают свою профессиональную карьеру системные аналитики, познавая свою роль в
жизненном цикле как часть продолжающейся поддержки пользователей. Они помогают менеджерам пользователей обеспечить описание
информационных потребностей и мотивы выполнения проекта, который будет в дальнейшем оценен при выборе среди всех поданных
проектов и который когда-нибудь будет утвержден и перейдет на
этап запуска и планирования.
Итак, проекты идентифицируются, как при нисходящей, так и восходящей инициативе. Формальная сторона этой процедуры может
сильно изменяться от организации к организации. Так как ограниченные ресурсы препятствуют разработке всех предложенных систем,
большинство организаций осуществляют некоторый процесс классификации и ранжирования достоинств каждого проекта. Проекты, считающиеся несовместимыми с глобальными целями организации, вводящие избыточность по функциональности относительно существующей системы, или не являющиеся необходимыми, таким образом,
удаляются из рассмотрения.
Классификация и ранжирование проектов разработки. Другое
главное действие процесса идентификации и выбора направлено на
оценку относительных достоинств потенциальных проектов. Как и на
предшествующем шаге, классификация и ранжирование проектов
может быть выполнена менеджерами высшего уровня, подготовительной комиссией, подразделениями организации или группой разработки информационных систем. Кроме того, критерий, используемый при определении относительных достоинств любого данного
проекта, может меняться. Широко применяемые критерии для оценки
проектов приведены в табл. 5.1. В любой данной организации в про199
цессе классификации и ранжирования могут быть использованы один
или несколько критериев.
Таблица 5.1
Возможные критерии оценки при классификации
и ранжировании проектов
Критерий оценки
Анализ цепочки наращения
(добавления) стоимости
Стратегическая ориентация
Потенциальные выгоды
Наличие ресурса
Размер проекта/продолжительность
Технические трудности/риски
Описание
Степень, с которой действия наращивают стоимость
и расходы при разработке изделий и/или услуг
Степень, с которой проект оценивается как полезный в достижении организацией ее стратегических
целей и решении долгосрочных задач
Степень, с которой проект оценивается как улучающий прибыль, обслуживание клиентов и т. д. и
продолжительность действия этих выгод
Количество и тип ресурсов, требуемых проектом, и
их наличие
Количество лиц и продолжительность времени, необходимых для выполнения проекта
Уровень технической сложности для успешного выполнения проекта в пределах выделенного времени
и ресурсов
Фактически критерии, используемые для оценки проектов, меняются в зависимости от организации. Если, например, организация использует подготовительную комиссию, она может выбрать проведение ежемесячных или ежеквартальных заседаний, для рассмотрения
проектов, используя при этом множество критериев. На таких заседаниях новые запросы на проекты могут рассматриваться относительно
уже идентифицированных проектов, а также выполняемых и контролируемых проектов. Относительные оценки проектов используются
для руководства в завершающем действии выбора проектов.
Для оценки проектов разработки информационных систем широко
применяется известный метод, называемый анализ по цепочке наращения (приращения, добавления) стоимости. Этот метод состоит в
анализе деятельности организации по созданию изделий и/или обслуживания для определения, где добавляется стоимость, и где про200
Производственная
деятельность
Поддержка производства
исходят расходы. С получением ясного понимания своей цепочки организация может достичь улучшения рабочих процессов и характеристик. Проектам информационных систем, обеспечивающих наибольший выигрыш для цепочки приращения стоимости, предоставляются
большие приоритеты.
Как можно полагать, информационные системы стали одним из
главных способов для осуществления перемен и улучшений в цепочке приращения стоимости организаций. Многие организации, например, используют Интернет для обмена важной бизнес-информацией с
поставщиками и заказчиками, такой как заказы и счета. Для проведения анализа по цепочке наращения стоимости необходимо представить организацию как протяженный процесс (рис. 5.1), состоящий из
цепочки более простых процессов, соединенных между собой входами и выходами.
Инфраструктура компании
(общее руководство, учет, финансы, стратегическое планирование)
Управление трудовыми ресурсами
(наем, обучение, работа с кадрами)
Разработка технологий
(исследования и разработка, улучшение продукта и процесса)
Снабжение
(приобретение сырья, оборудования и комплектующих)
Входная
логистика
(сырье,
погрузочноразгрузочные
работы и
складирование)
Рабочие
процессы
(механическая
обработка,
сборка,
испытания)
Выходящая
логистика
(складирование и
дистрибуция
готовых
изделий)
Маркетинг
и сбыт
(реклама,
продвижение,
ценообразование,
отношения
канала
реализации)
Размер
прибыли
Услуги
(установка,
ремонт,
запасные
части)
Рис. 5.1. Цепочка приращения стоимости организации
На одной стороне процесса находятся входы в организацию,
например, материалы и комплектующие, которые закупает организация. Внутри организации эти материалы и ресурсы некоторым образом интегрируются, создавая продукцию и услуги. С другой стороны
процесса находятся выходы, представляющие продукцию и услуги, ко201
торые продвигаются и продаются маркетингом и затем поставляются
заказчикам. Осуществляя анализ цепочки приращения стоимости необходимо вначале осмыслить каждое действие, функцию и процесс, где
добавляется или должна добавляться стоимость. Далее необходимо
определить расходы (и факторы, движущие расходы, или заставляющие
их изменяться) внутри каждой из областей. После осмысления цепочки
приращения стоимости и расходов необходимо осуществить сравнение
этой цепочки приращения стоимости и расходов с подобными цепочками других организаций, предпочтительно конкурентов. Осуществляя
такое сравнение, представляется возможным определить приоритеты
применения проектов информационных систем.
Выбор проектов разработки информационных систем. Окончательное действие процесса идентификации и выбора проектов состоит непосредственно в выборе проектов для дальнейшей разработки.
Выбор проектов представляет собой процесс рассмотрения краткосрочных и долгосрочных проектов и выбора из них тех, которые
наиболее пригодны для достижения бизнес-целей. Кроме того, с изменением со временем условий относительная важность любого проекта может существенно изменяться. Таким образом, идентификация
и выбор проектов является важной и непрерывной деятельностью.
В процессе принятия решений о выборе проекта должно быть рассмотрено множество важных факторов. На рис. 5.2 показано, что решения по выбору проекта должны учитывать осознанные потребности организации, существующие системы, выполняемые проекты, доступность ресурсов, критерии оценки, текущие бизнес-условия и
представления лиц, принимающих решения.
Процесс выбора имеет на выходе множество возможных альтернативных решений. Проект может быть принят или отклонен. Принятие
обычно означает, что тем самым получено санкционирование на выделение фондов для следующей фазы разработки проекта. Отклонение
означает, что проект больше не будет рассматриваться на предмет возможной разработки. Однако существуют и другие возможные решения – проект может быть принят условно, или принят с ожиданием
202
утверждения или требуемых ресурсов или доказательств, что конкретный сложный аспект системы может быть разработан и т. п.
Осознанные и реальные
потребности
Существующие и
доступные
ресурсы
Выход принятия решения
Список потенциальных и
выполняемых проектов
Решение выбора проекта
Текущая среда
организации
Критерии оценки
* Принять проект
* Отвергнуть проект
* Отложить проект
* Изменить направленность
проекта
* Доказать концепцию
* Рассмотреть конечным
пользователем
Рис. 5.2. Решения по выбору проекта
5.1.2. Выход и результаты
Основным выходом рассмотренного первого этапа является график отдельных проектов разработки систем, поступивших из нисходящих и восходящих источников для перехода к следующей фазе
жизненного цикла – запуска и планирования (рис. 5.3).
Результат этого этапа состоит в достигнутой уверенности, что выбору проекта было уделено должное внимание с ясным осмыслением
его возможностей оказания помощи организации в достижении ее целей. Благодаря принципу поэтапного выполнения выбранный проект
не обязательно приведет к работающей системе. Выполнение проекта
может быть остановлено. Поэтапное выполнение - это стратегия в
анализе и проектировании систем, в которой проект оценивается после каждого этапа. При этом каждый раз должно обосновываться его
продолжение. После каждого последующего этапа жизненного цикла
разработки систем все исполнители группы разработки проекта и ру203
ководители организации подвергают проект переоценке для определения, произошло ли за это время изменение бизнес-условий, или не
снизилась ли значимость проекта в связи с более детальным осмыслением расходов, выгоды и рисков.
Источники
потенциальных проектов
Идентификация и
выбор проектов
Запуск и планирование
проекта
Нисходящие
Высшее руководство
Подготовительная комиссия
Оценивание,
ранжирование и
планирование
проектов
Планы проектов
1. ...
2. ...
3. ...
Восходящие
Подразделения пользователей
Группа разработки
Рис. 5.3. Идентификация и выбор проектов
Многие организации считают, что для принятия хороших решений
по выбору проектов и для обеспечения правильного направления требуется ясное осмысление глобальной бизнес-стратегии и целей организации. Это означает, что ясное осмысление бизнеса и желательной роли
информационных систем в достижении целей организации является
предварительным условием для улучшения процесса идентификации и
выбора. В следующем параграфе рассматривается процесс, связанный с
корпоративным стратегическим планированием и планированием информационной системы, устанавливающий бизнес-стратегию и определяющий роль информационных систем в их планах.
204
5.2. Корпоративное планирование и планирование
информационной системы
Несмотря на существующие многочисленные мотивы в пользу
тщательного планирования идентификации и выбора проектов, организации традиционно не используют систематический процесс планирования размещения информационных ресурсов. Вместо этого
проекты часто представляют собой попытки решения изолированных
проблем организации.
Фактически, организации часто задаются вопросом: «Какие процедуры (прикладные программы) требуются для решения этой отдельной проблемы, в том ее виде, в котором она существует сегодня?» Недостаток этого подхода состоит в том, что процедуры, требуемые организации, склонны к изменению во времени с изменением среды.
Например, компания может решить изменить метод выставления счета
заказчикам или университет может изменить свою процедуру регистрации студентов. Когда происходят изменения, становится опять необходимой модификация существующей информационной системы.
В противоположность этому, подходы, основанные на планировании, задаются вопросом: «Какие требования к информации (или к
данным) удовлетворят потребности принятия решений или бизнеспроцессов предприятия сегодня, а также в будущем. Главное преимущество этого подхода состоит в том, что информационные потребности организации менее вероятно склонны к изменениям (или
изменяются более медленно) чем ее бизнес-процессы. Например, пока организация не изменит основательно свой бизнес, ее основные
структуры данных могут оставаться достаточно стабильными. При
этом процедуры, используемые для доступа и обработки этих данных, могут изменяться многократно в течение этого периода. Таким
образом, сложность во многих организациях состоит в создании совершенных информационных моделей, определяющих данные, относительно независимо от языков и программ, применяемых для доступа, добавления и изменения данных
205
Для получения всей выгоды от подхода, основанного на планировании при идентификации и выборе проектов, организация должна
осуществлять анализ информационных потребностей и планов ее
проектов с особым вниманием. Отсутствие необходимого внимания
может привести к созданию баз данных и систем, которые поддерживают отдельные процессы, но не обеспечивают совместное использование ресурсов всей организацией. Более того, при изменении бизнеспроцессов недостаточная интеграция данных и систем окажет отрицательное влияние на скорость, с которой организация должна осуществить перемены в бизнес стратегии или процессах.
Потребность в улучшении идентификации и выборе проектов информационных систем становиться легко очевидной при принятии во
внимание следующих факторов.
x Стоимость информационных систем неуклонно повышается, и в
некоторых организациях достигает уже 40% от общих инвестиций.
x Многие системы не могут иметь дело с приложениями, действие
которых распространяются через границы организации.
x Многие системы не рассматривают важнейшие проблемы бизнеса как единое целое и не поддерживают стратегические приложения.
x Избыточность данных часто выходит из-под контроля, и пользователи мало уверены в качестве данных.
x Стоимость сопровождения систем также выходит из-под контроля, поскольку существующие старомодные и плохо спланированные системы должны постоянно пересматриваться.
x Очереди заказов на разработку приложений часто простираются
на срок три года и более, и обеспокоенные конечные пользователи
вынуждены создавать (или покупать) свои собственные системы, часто усугубляя избыточность баз данных и несовместимость систем.
Тщательное планирование и выбор проектов само по себе определенно не решит все эти проблемы. Только упорядоченный процесс,
движимый направлениями высшего руководства, является предпо206
сылкой для наиболее эффективного применения информационных систем для достижения целей организации.
5.2.1. Корпоративное стратегическое планирование
Необходимость принятия эффективных решений выбора проекта,
как правило, приводит к очевидной мысли, связанной с выяснением
текущего состояния организации, видением ее желаемого состояния в
будущем и определением пути перехода в желаемое будущее состояние. Рис. 5.4 представляет это как процесс, состоящий их трех шагов.
Первый шаг концентрируется на усилении понимания текущего состояния предприятия. Далее высший менеджмент должен определить,
каким оно видит предприятие в будущем. После этого должен быть
разработан стратегический план для руководства переходом. Процесс
разработки и совершенствования моделей предприятия для настоящего и будущего, так же как и стратегии перехода, часто называют корпоративным стратегическим планированием. Корпоративное стратегическое планирование это продолжающийся процесс определения
миссии, целей и стратегий организации.
В течение корпоративного стратегического планирования руководители обычно разрабатывают формулировку миссии, формулировку
будущих целей корпорации и стратегий, предназначенных для помощи организации в достижении ее целей.
Все успешные организации имеют миссию. Формулировка миссии
компании обычно на простом языке определяет, в чем состоит ее деятельность. Миссия формулируется путем ответа на вопрос: «Что мы
как организация хотим достичь?» Пример возможной формулировки
миссии компании представлен на рис. 5.5. После анализа этой формулировки становится ясно, что компания занимается конструированием и продажей высококачественной мебели из древесины широкому кругу лиц для применения в быту, а также офисам и учреждениям,
таким как университеты и больницы. Их нее также ясно, что компания не занимается стальными шкафами для документов и не осу207
ществляет реализацию своей продукции через оптовую сеть дистрибуции. Основываясь на формулировке миссии, можно сделать вывод,
что компании не требуется информационная система розничной торговли, вместо этого для нее бы больше подошла информационная система трудовых ресурсов, как более согласующаяся с целями компании.
Шаг 1
Предприятие в текущем
состоянии
Шаг 2
Будущее состояние
предприятия
Шаг 3
Стратегический план
Рис. 5.4. Корпоративное стратегическое планирование
Формулировка миссии компании
Наша деятельность состоит в дизайне, производстве и продаже в
сеть розничной торговли высококачественной мебели из дерева
для использования ее в быту, офисах и учреждениях. Мы дорожим качеством нашего товара и нашими отношениями с покупателями и поставщиками. Мы рассматриваем наших работников
как наиболее решающий ресурс.
Рис. 5.5. Пример формулировки миссии компании
Пример формулировки миссии другой широко известной компании Bridgestone приводится на рис. 5.6. Читателю предлагается самостоятельно провести анализ ее смысла и значения в контексте внешнего маркетинга, внутрихозяйственной деятельности компании и
планирования ее информационной системы.
208
Миссия Bridgestone Corporation
Наша миссия с самого начала продолжает строго придерживаться: служения обществу через высококачественные продукты.
Наша экологическая миссия служит дополнением к этому заявлению – мы будем не просто предоставлять нашим потребителям
высококачественные продукты, но мы будем также развивать
свой бизнес таким образом, что поможет обеспечить здоровую
окружающую среду для будущих поколений.
Рис. 5.6. Формулировка миссии компании Bridgestone Corporation
После определения миссии организация может сформулировать
свои цели. Формулировки цели – это серия формулировок, выражающих количественные и качественные целевые установки для достижения желаемого будущего положения. Формулировка целей ссылается на широкие и неопределенные во времени целевые установки
организации. Она состоит из серии целей, которые могут быть, как
качественными, так и количественными, и обычно не содержат подробностей, которые, как правило, склонны к изменению во времени.
Цели иногда и не совсем точно называют критическими факторами
успеха. Цели предприятия определяют его стратегию и отвечают на
вопрос: «Как мы, организация, собираемся выполнить нашу миссию?» Пример целей компании, имеющих наибольшее отношение к
ее миссии рис. 5.5, представлен на рис. 5.7. Например, цель, указанная под номером два, связана с тем, какими видит компания свои отношения с клиентами. Эта цель предполагает, что компания, возможно, хочет инвестировать в электронный обмен данными или оперативную систему статуса заказов, которая, могла бы способствовать
высококачественному обслуживанию клиентов. После того как компания определила свою миссию и цели, может быть сформулирована
конкурентная стратегия.
209
Формулировка целей
1. Компания будет прилагать усилия для увеличения рынка и рентабельности (высшая цель).
2. Компания станет рыночным лидером в обслуживании покупателей.
3. Компания станет инновационной в использовании технологий для
опережения конкурентов в выпуске на рынок новой продукции.
4. Компания будет использовать наименьшее количество высококвалифицированного персонала, необходимого для достижения ее высшей цели.
Рис. 5.7. Пример формулировки целей компании
Конкурентная стратегия - это метод, при помощи которого организация пытается выполнить свою миссию и достичь цели. По существу, стратегия является планом действий в конкурентном, деловом
мире. Существующая теория определяет три базовые конкурентные
стратегии - стратегия абсолютного лидерства в издержках или стратегия недорогого изготовителя, стратегия дифференциации продукта
или услуги и стратегия фокусирования на определенной группе покупателей, виде продукции или географическом сегменте рынка или
стратегия ниш (табл. 5.2). Эти базовые стратегии дают возможность
легко сравнить две компании одной и той же отрасли, которые не используют одинаковые конкурентные стратегии. В дополнение, организации, использующие различные конкурентные стратегии, часто
имеют различные информационные потребности для принятия решений. Например, компании Rolls Royce и GEO представляют две линии автомобилей с различными стратегиями, одна из них – это высоко престижная линия сверхроскошной ниши, в то время как другая
является линией невысокой стоимости для общего рынка автомобилей. Rolls Royce для помощи в управлении ключевыми целями компании может построить информационные системы для сбора и анализа информации об удовлетворенности клиентами ее продукцией.
Альтернативно, GEO может построить системы для отслеживания за210
вода и использования комплектующих материалов для управления
деятельностью, связанной со стратегией недорогого изготовителя.
Таблица 5.2
Общие конкурентные стратегии
Стратегия
Стратегия недорогого
изготовителя (Абсолютное лидерство в издержках).
Описание
Стратегия отражает конкуренцию в промышленности на основе издержек потребителя товара или обслуживания. Например, в автомобильной промышленности компания Hyundai ЮжноКорейского производства представляет собой
линию продуктов, которые конкурируют на основе низкой стоимости.
Стратегия дифференци- Эта конкурентная стратегия отражает капиталиации продукта или
зацию (извлечение выгоды) на ключевом критеуслуги.
рии изделий, востребованном рынком (например, высокое качество, стиль, эксплуатационные
свойства, вместительность и представление товара таким образом, что потребителям он кажется отличным от продукции конкурентов). В автомобильной промышленности многие производители пытаются выделить свои продукты на
основе качества (например, «У Форда, качество
на первом месте»).
Стратегия фокусирова- Характеризуется определенной линией (модения на определенной
лью) поведения фирмы в области разработки,
группе покупателей, ви- производства, продвижения, сбыта, усовершенде продукции или гео- ствования и т. п. а также поиском и захватом
графическом сегменте свободных сегментов рынка. Например, одной
рынка.
из рыночных ниш в автомобильной промышленности является рыночная ниша рынка спортивных автомобилей с откидным верхом. Внутри этого рынка некоторые производители могут
использовать стратегию невысокой стоимости
или стратегию дифференциации, основанную на
эксплуатационных характеристиках или стиле.
211
Для эффективного развертывания ресурсов, таких как создание организации маркетинга и продаж, или для построения наиболее эффективных информационных систем, организация должна ясно осознавать свою миссию, цели и стратегию. Недостаточное осознание
этого делает невозможным определение деятельности, являющейся
существенной для достижения бизнес целей. С точки зрения разработки информационных систем управления определение деятельности,
которая является наиболее важной для достижения бизнес целей, существенно увеличивает у организации возможности для определения той
деятельности, которая наиболее нуждается в поддержке информационными системами. Другими словами, проект разработки информационной системы может быть идентифицирован и выбран только через ясное понимание миссии, целей и стратегии организации
5.2.2. Планирование информационной системы
Другой процесс планирования, который может оказать существенное влияние на качество идентификации и решения выбора проекта
называется планированием информационной системы. Планирование
информационной системы представляет собой упорядоченный метод
оценки информационных потребностей организации и определения
информационных систем, баз данных и технологий, которые наиболее
лучшим образом удовлетворяют этим потребностям. Это означает, что
в течение планирования информационной системы высшее руководство информационной системы организации, отвечающие за этот план,
должны выполнить моделирование текущих и будущих информационных потребностей организации, и разработать стратегии и планы проекта для перехода с текущих информационных систем и технологий к
их желаемому будущему состоянию. Планирование информационной
системы является нисходящим процессом, который принимает во внимание внешние силы, отрасль промышленности, экономику, относительный размер, географический регион важные для успеха компании.
Это означает, что процесс планирования информационной системы
212
должен рассматривать систему и технологии с точки зрения того, как
они могут помочь предприятию достичь его целей, определенных в
процессе корпоративного стратегического планирования.
На рис. 5.8 представлены три ключевые функции рассматриваемого
процесса моделирования. Подобно корпоративному стратегическому
планированию планирование информационной системы состоит из
трех шагов. Первый шаг заключается в оценке текущих ресурсов, связанных с информационной системой – трудовых ресурсов, данных,
процессов и технологий. Следующий шаг состоит в разработке целевых
моделей этих ресурсов. Эти модели отражают желаемое будущее состояние ресурсов, необходимых организации для достижения целей,
определенных в процессе стратегического планирования. В завершение
планирования определяется ряд плановых проектов, которые призваны
оказать помощь в переходе организации из ее текущего в будущее желаемое состояние.
Текущее состояние:
Шаг 1
* листинг ручных и автоматизированных процессов
* листинг ручных и автоматизированных данных
* реестр технологий
* реестр трудовых ресурсов
Будущее состояние:
Шаг 2
* шаблоны ручных и автоматизированных процессов
* шаблоны ручных и автоматизированных данных
* шаблоны технологий
* шаблоны трудовых ресурсов
График проектов:
Шаг 3
------------------------------------------------------:
------------------------------------------------------------
Рис. 5.8. Три шага процесса планирования информационной системы
213
Корпоративное стратегическое
планирование
Планирование информационных систем
Текущее состояние:
Текущее состояние
предприятия
* перечень ручных и автоматизированных процессов
* перечень ручных и автоматизированных данных
* реестр технологий
* реестр трудовых ресурсов
Будущее состояние:
Будущее состояние
предприятия
* шаблоны ручных и автоматизированных процессов
* шаблоны ручных и автоматизированных данных
* шаблоны технологий
* шаблоны трудовых ресурсов
График проектов:
Стратегический план
------------------------------------------------------:
------------------------------------------------------------
Рис. 5.9. Параллельное выполнение корпоративного стратегического
планирования и планирования информационных систем
Описание текущего состояния. Для описания текущего состояния организации обычно применяют наиболее широко используемый
подход, называемый нисходящим планированием. Нисходящее планирование – это общая методика планирования информационных систем, которая пытается достичь широкого осмысления потребностей
информационной системы для организации в целом. Подход начинает
с проведения расширенного анализа миссии организации, целей,
стратегии и определения информационных требований, соответствующих целям. Такой подход к планированию информационных систем
фактически явно определяет его название «высокая степень представления организации с активным привлечением менеджмента высшего уровня». Нисходящий подход к планированию информацион214
ных систем имеет несколько преимуществ перед другими подходами
планирования. Краткие формулировки этих преимуществ приведены
в табл. 5.3.
Таблица 5.3
Преимущества подхода нисходящего планирования
Преимущество
Более широкое представление.
Улучшенная
интеграция.
Описание
Если не рассматривать сверху, то информационные системы могут быть применены без понимания предприятия
с точки зрения общего управления.
Если не рассматривать сверху, то может быть реализована
полностью новая информационная система управления, а
не развитие существующей системы.
Улучшенная Если не рассматривать сверху, то планировщики могут
поддержка
испытывать недостаток обоснованного признания меменеджмента неджментом роли информационных систем в оказании им
помощи в достижении целей предприятия.
Более лучшее Если не рассматривать сверху, планировщики могут испонимание.
пытывать недостаток понимания необходимого для применения информационных систем на всем предприятии в
целом, а не просто на отдельных участках работ.
В противоположность подходу нисходящего планирования подход
восходящего планирования требует идентификации проблем предприятия и возможностей, которые используются для определения
проектов. Использование восходящего подхода для создания планов
информационных систем может оказаться быстрее и дешевле для
разработки, чем использование нисходящих подходов. Он также обладает преимуществами в идентификации неотложных проблем организации. Однако его применение может привести в результате к
несопоставимым информационным системам или базам данных, являющимся избыточными или требующим существенной переделки
при осуществлении интеграции в дальнейшем.
215
Восходящее планирование – это общая методика планирования
информационных систем, которая идентифицирует и определяет проекты разработки информационных систем, основываясь на текущих
экономических задачах или использовании преимуществ некоторых
возможностей деловой деятельности.
Процесс описания текущего состояния начинается с подбора состава
группы планирования, включающей в себя руководителей, сертифицированных для решения задач моделирования текущего состояния. Для
решения этой задачи группа должна выполнить анализ документации
компании; интервьюировать менеджеров, руководителей и заказчиков,
а также провести подробный обзор конкурентов, рынка, продукции и
финансов. Для представления текущего состояния должны быть собраны следующие виды информации: идентификация всех мест расположения организации, ее подразделений, функций, процессов, данных
(или объектов данных) и информационных систем.
Например, размещение организации может быть представлено в
виде списка географических мест, в которых действует компания
(расположение головного офиса и офисов отделений). Подразделения
организации представляются списком людей и/или служб предприятия, которые действуют внутри организации. Таким образом, подразделения организации могут включать вице-президента по производству, менеджера по продажам, торговый персонал и служащих.
Функции представляют собой набор различных видов деятельности
организации, проводимой для выполнения ежедневных операций
предприятия. Примеры функций могут включать в себя исследование
и развитие, совершенствование персонала, производство, закупки и
продажи. Процессы представляют собой список ручных или автоматизированных процедур, разработанных для поддержки бизнесфункций. Примеры бизнес процессов могут включать в себя обработку заработной платы, выставление счетов заказчикам отправку товара. Объекты данных представляют список информационных элементов генерируемых, обновляемых, удаляемых или используемых бизнес-процессами. Информационные системы представляют автомати216
зированные или неавтоматизированные системы, используемые для
преобразования данных в информацию для поддержки бизнес процессов. Например, рис. 5.10 представляет часть бизнес функций, объектов данных и информационных систем организации. Рис. 5.11
представляет декомпозицию нескольких функций этой организации в
более детальные поддерживающие функции.
Функции
Планирование
предприятия
Разработка изделия
Маркетинг и продажи
Производственная
деятельность
Финансы и учет
Трудовые ресурсы
Данные
Информационные
системы
Заказчик
Обработка заработной
Изделие
платы
Поставщик
Дебиторы
Исходные материалы Кредиторы
Заказ
Обработка карточек
Счет
табельного учета
Оборудование
Управление запасами
Рис. 5.10. Информация планирования информационных систем
Планирование выпуска и сбыта продукции
Анализ состояния рынка
Прогнозирование сбыта
Разработка изделия
Концептуальный анализ
Проектирование изделия
Маркетинг и сбыт
Маркетинговые исследования
Выполнение заказа
Продажа по каналам сбыта
Производственная деятельность
Планирование производства
Производство
Сборка
Доводка
Финансы и учет
Бюджетирование капиталовложений
Счета дебиторов
Счета кредиторов
Трудовые ресурсы
Наем
Обучение
Рис. 5.11. Функциональная декомпозиция
217
После создания этих перечней может быть разработан ряд матриц
для перекрестных связей между различными элементами организации. Разрабатываемые матрицы обычно включают в себя следующие
виды.
x Расположение – функция. Матрица определяет функции предприятия, выполняемые в различных местах расположения организации.
x Расположение – подразделение. Матрица определяет подразделения организации, расположенные в или взаимодействующие с конкретными местами ведения деятельности.
x Подразделение – функция. Эта матрица определяет отношение
между подразделениями организации и каждой бизнес-функцией.
x Функция – цель. Эта матрица определяет функции, являющиеся
существенными или желательными при достижении каждой цели организации.
x Функция – процесс. Матрица определяет процессы, используемые для поддержки каждой бизнес-функции.
x Функция-объект данных. Матрица определяет использование
объектов данных каждой бизнес-функцией.
x Процесс – объект данных. Определяет применение каждого вида данных каждым процессом (сбор, использование, обновление,
уничтожение).
x Процесс - информационная система. Эта матрица определяет,
какая информационная система используется для поддержки каждого
процесса.
x Объект данных – информационная система. Эта матрица определяет,
какие данные создаются, обновляются, используются или уничтожаются
каждой системой.
x Информационная система – цель. Матрица определяет, какая
информационная система поддерживает какую из запланированных
бизнес-целей.
Например, рис. 5.12 представляет часть данных матрицы «Объект
данных – функция».
218
Маркетинг и сбыт
Маркетинговые исследоваX
ния
Выполнение заказа
X
Продажа через канал сбыта X
Производственная
деятельность
Планирование производства
Производство
Сборка
Доводка
Финансы и учет
Бюджетирование капиталовложений
Счета дебиторов
X
Счета кредиторов
Трудовые ресурсы
Наем
Обучение
Наряд
Счет
Бизнес-функции
Заказчик
Изделие
Поставщик
Исходные
материалы
Заказ
Обрабатывающий
центр
Оборудование
Работники
Типы объектов данных
X
X
X
X
X
X X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Рис. 5.12. Матрица «Объект данных – функция»
Символ «Х» в ячейках этой матрицы показывает использование
данных бизнес-функциями. Более подробное представление использования данных может быть показано в матрице «Процесс – объекты
данных» (не представленной в данной работе), где ячейки могли бы
содержать следующие коды: «С» – для ассоциируемых процессов, создающих или осуществляющих сбор данных соответствующих объектов, «R» – для поиска или использования, «U» – для обновления и
«D» – для уничтожения.
Различные матрицы содержат различные отношения, в зависимости от того что они представляют. Например, рис. 5.13 представляет
часть матрицы «Информационная система – цель».
219
Обработка транзакций
Отслеживание заказов
Обработка заказов
Планирование работы предприятия
Заработная плата
Счета кредиторов
Счета дебиторов
Управление наличностью
Управленческие отчеты
Управление сбытом
Анализ регионов сбыта
Управление запасами
Планирование производства
F
С
F
С
С
С
F
F
С
F
F
С
F
С
С
С
С
F
С
F
F
F
С
F
Отличительность
Кадровый
состав
Инновация
Информационная система
Обслуживание
Прибыль
Цель
F
F
F
С
F
С
F
F
F
F
Рис. 5.13. Матрица «Информационная система – цель»
В этой матрице цели, которые в текущий момент поддерживаются
существующей информационной системой, отмечены символом «С», а
цели, намеченные для поддержки будущей системой, отмечены символом «F». Одним из способов, когда эта матрица могла бы быть полезной при выборе проектов на основе восходящего подхода, могло
быть следующее. Предположим, что поступил запрос на внесение изменений в систему заработной платы. Как показывает символ «С» в
строке «Заработная плата» и столбце «Прибыль», что текущая система
поддерживает цель получения прибыли. Запрошенные изменения для
того, чтобы могли считаться заслуживающими внимания, должны
привнести вклад в другие цели (например, в трудовые ресурсы). Подобно этому, возможно применение различных видов анализа влияния, использующих одну матрицу или их комбинацию. Путем создания и анализ этих матриц планировщики могут получить ясное понимание текущего состояния организации. Краткий сценарий использования матриц для планирования систем представлен на рис. 5.14.
220
В течение процесса планирования информационных систем (до идентификации и выбора
отдельных проектов) проводится большая невидимая аналитическая работа. В этот период, продолжающийся от шести месяцев до одного года, группа планирования информационных систем разрабатывает и анализирует многочисленные матрицы, подобные рассмотренным выше. Матрицы разрабатываются для описания текущего и будущего представления организации. Матрицы текущего состояния называют матрицами «as is « (как
есть). Другими словами они описывают мир, как он сейчас есть. Матрицы целевого или
будущего состояния называют матрицами «to be». Сравнение текущего и будущего представлений обеспечивает понимание отношений, существующих в важной деловой информации, и что наиболее важно, формирует основу для идентификации и выбора специфических проектов разработки. Многие средства CASE обеспечивают возможности, которые помогут извлечь смысл из этих матриц, по крайней мере, тремя способами.
1. Управление информаций. Большая часть работы со сложными матрицами состоит в
координации информации. Используя возможности словаря репозитория средств CASE
можно осуществлять определение и модификацию терминов (таких как бизнес-функции,
процессы и объекты данных) в одном месте. Все планировщики, следовательно, будут обладать возможностью использования последней информации.
2. Конструирование матриц. Система отчетов репозитория средства CASE позволяет
легко создавать отчеты о матрицах. Так как информация планирования может быть изменена в любое время любым членом группы планирования, то простой и легкий метод занесения изменений и создания отчетов, учитывающих самые последние изменения, является неоценимым для процесса планирования.
3. Анализ матриц. Возможно, что наиболее важной функцией средств CASE, предоставляемой планировщикам, является возможность выполнять сложный анализ внутри и между матрицами. Этот анализ часто называют кластеризацией по сходству. Таким образом,
кластеризация по сходству является процессом упорядочения информации матриц, в результате которого кластеры информации с некоторым заранее определенным уровнем или
типом сходства размещаются друг за другом в отчете о матрице. Например, кластеризация по сходству матрицы «Процесс – объекты данных» мог бы создать приближенно
поблочную диагональную матрицу с процессами, которые используют подобные объекты
данных и расположенными в соседних строках, и объектами данных, используемыми
совместно одними и теми же процессами и сгруппированными в соседних столбцах. Этот
общий вид анализа может быть использован планировщиками для определения элементов, появляющихся часто совместно. Такая информация позволяет наиболее эффективно
сгруппировать и связать объекты планирования (т. е. связать данные с процессами, функциями, местонахождением и т. д.). Например, данные, используемые общим набором
процессов, могут рассматриваться как кандидаты для специфической базы данных. Бизнес-процессы, связанные со стратегически важной целью получат, вероятно, больше внимания при формировании менеджерами запроса на изменение системы в этих областях.
Рис. 5.14. Управление матрицами средствами CASE
Описание целевого (будущего) состояния, тенденций и ограничений. После описания текущего состояния следующим шагом процесса планирования информационных систем является определение
целевого состояния, которое отражает желаемое будущее состояние
221
организации. Это означает, что целевое состояние состоит из желаемого состояния мест расположения, подразделений, функций, процессов,
данных и информационных систем (рис. 5.8). Например, если желаемым будущим состоянием организации является открытие нескольких
филиалов компании или новой производственной линии, которые требуют несколько новых должностей, функций, процессов и данных, то
это потребует изменений в большинстве перечней и матрицах, для отражения этой новой концепции. В дополнение к ограничениям организации целевое состояние должно быть разработано в свете тенденций
технологий и бизнеса. Это означает, что для помощи в обеспечении
отражения целевым состоянием этих положений должны также создаваться перечни тенденций бизнеса и ограничений.
Вкратце, для создания будущего состояния, планировщики должны, во-первых, отредактировать их первоначальные списки и записи
желаемых мест расположения, подразделений, функций, процессов,
данных и информационных систем с учетом ограничение и тенденций среды организации (например, время, ресурсы, эволюция технологий, конкуренция и т. п.). Далее, должны быть также обновлены
матрицы для приведения в соответствии содержащейся в них информации с желаемым будущим состоянием. После этого планировщики
концентрируют свое внимание на различиях между текущими и будущими перечнями и матрицами для определения проектов и стратегий перехода.
Разработка стратегии перехода и планов. После завершения создания текущего и будущего состояния, группа планирования информационной системы разрабатывает подробную стратегию перехода и план. Этот план должен быть всесторонним, отражающим широкие и долгосрочные положения, а также достаточные подробности,
используемые всеми уровнями менеджмента относительно того, что
необходимо сделать, как, когда и кем. Компоненты типичного плана
информационных систем в общих чертах даны на рис. 5.15.
План информационной системы обычно представляет собой всесторонний документ, который рассматривает краткосрочные и долго222
срочные потребности организации. Эти потребности, идентифицируемые планом, как правило, отражаются в серии проектов (рис. 5.16).
1. Миссия организации, цели и стратегия
Кратко описывают миссию, цели и стратегию организации. Представляются
также кратко текущее и будущее представление компании (т. е. где находится
компания и где она хочет находиться).
2. Информационная опись
Этот раздел обеспечивает краткое изложение различных бизнес-процессов,
функций, объектов данных и информационных потребностей предприятия. Эта
опись рассматривает как текущие, так и будущие потребности.
3. Миссия и цели информационной системы
Описание основной роли, которую будет выполнять информационная система в
организации для ее преобразования из текущего в будущее состояние. Несмотря
на то, что будущее состояние позже может быть пересмотрено, оно представляет текущую наилучшую оценку глобальной роли информационной системы в
организации.
4. Ограничения на разработку информационной системы
Кратко описывает ограничения накладываемые технологиями и текущим уровнем ресурсов внутри предприятия – финансовые, технологические и кадровые.
5. Общие системные потребности и долгосрочные стратегии информационной
системы
Представляет краткое изложение общих системных потребностей компании и
набор долгосрочных (2-5 лет) стратегий, избранных службой информационной
системы предприятия для удовлетворения этих потребностей.
6. Краткосрочный план
Представляет подробную опись существующих информационных проектов и
систем и подробный план проектов, которые будут разработаны или продвинутся вперед в течение текущего года. Эти проекты могут быть следствием долгосрочных стратегий информационных систем или запросов от менеджеров, которые уже утверждены и находятся на некотором этапе жизненного цикла.
7. Заключение
Содержит вероятные, но еще не определенные события, которые могут повлиять на план, опись элементов перемен в компании, как это представляется на
данный момент, и описание оценки их влияния на план.
Рис. 5.15. Краткое содержание плана информационных систем
Проекты долгосрочного плана направлены на построения основы
для будущих проектов (такой, как преобразование базы данных со
223
старой технологии в новую технологию). Проекты краткосрочных
планов состоят из специфических шагов для устранения разрыва между текущей и желаемой системами, или для соответствующего реагирования на изменяющиеся бизнес-условия. Нисходящие (или управляемые планом) проекты объединяются с набором восходящих проектов,
или проектов, управляемых потребностями, представленных в качестве запросов на системные услуги менеджерами для формирования
краткосрочного плана разработки информационных систем.
План информационной системы:
1.
2.
3.
4.
5.
6.
7.
Миссия организации
Реестр информации
Миссия и цели информационной системы
Ограничения
Долгосрочный план
Краткосрочный план
Заключение
Проект 1
2
3
4
Рис. 5.16. Поток проектов разработки систем
Совместно, краткосрочные и долгосрочные проекты определяют
ясные направления для процесса выбора проектов. Краткосрочный
план включает не только проекты, идентифицированные в результате
процесса планирования, но также проекты, выбранные из восходящих
запросов. План информационной системы в целом может также оказывать влияние на все проекты разработки. Например, миссия и ограничения информационной системы могут приводить проекты к выбору определенных технологий или к акценту на определенные возможности приложений в процессе разработки систем.
224
5
5.3. Практический пример:
Планирование информационной системы
Основатель компании «Свежая выпечка», - хороший бизнесмен и
имеет некоторую подготовку в области бизнеса, менеджмента и информационных систем. Однако у него нет большого практического
опыта разработки. Он убежден, что методологии разработки систем это что-то хорошее и с интересом изучил соответствующую профессиональную литературу. Он понимает, что приобретение коммерческой методологии или/или интегрированного программного пакета –
это слишком дорого и неэффективно для небольшой компании. Поэтому он ищет собственный простой способ извлечения всех выгод,
которые обещают изученные им источники – создать целевую информационную систему, используя лучшее из того, что он изучил.
Ему очень нравится подход методологии информационной инженерии. Он особенно заинтересован в интеграции и автоматизации компании и хорошо понимает потенциальные выгоды от приема заказов
через Интернет, моделирования и оптимизации производства, управления внутренней логистикой и отношениями с клиентами.
Он знает о многих неудачах разработки информационных систем.
Его целью является значительное увеличение бизнеса с помощью инновационных форм применения информационных технологий. Он
хочет сделать деятельность более эффективной и менее дорогостоящей. Он также хочет использовать систему, исключающую влияние
существующих сегодня проблем. После составления формализованного описания текущего состояния своего предприятия («as is», раздел 4.4) он приступил к планированию информационной системы и
получил последовательно следующие выходные результаты.
x Проблемные области текущего состояния предприятия.
x Будущее состояние предприятия: (миссия, цели, конкурентная
стратегия, ключевые факторы успеха).
x Будущее состояние информационной системы (трудовые ресурсы, ручные и автоматизированные данные, функции предприятия).
225
x Будущие подсистемы информационной системы.
5.3.1. Проблемные области текущего состояния предприятия
Анализ модели текущего состояния компании «as is» раздела 4.4
позволил ему выявить ряд существующих проблемных областей, которые представлены на рис. 5.17. Эти, не решенные сегодня проблемы, отрицательно влияют на экономические результаты из-за завышенных затрат, упущенной выгоды, материальных, и других ресурсных потерь.
Проблемные области предприятия «Свежая выпечка»
1. Слабый контроль расхода используемого сырья в компании.
2. Несовершенство прогноза потребности в сырье.
3. Несовершенство прогноза потребности в продукции и планирования
производства.
4. Слабый контроль использования имеющихся производственных ресурсов.
5. Отсутствие динамического реагирования в реальном времени на изменяющиеся потребности клиентов.
6. Завышенные издержки при доставке продукции автотранспортом.
Рис. 5.17. Проблемные области предприятия «Свежая выпечка»
5.3.2. Планирование предприятия
Как это было рассмотрено, будущее состояние предприятия определяется его миссией, целями предприятия, конкурентной стратегией
и ключевыми факторами успеха.
Миссия предприятия. В формулировке миссии (рис. 5.18) компания
«Свежая вып5ечка» определило специфику своей деятельности и свое
отношение к выпускаемой продукции, ее конечным потребителям и работникам компании. Формулировка отражает основное предназначение,
смысл существования предприятия, выраженный через те выгоды, которое оно несет заинтересованным сторонам (клиентам и работникам).
226
Миссия предприятия «Свежая выпечка»
Наша деятельность состоит в разработке, производстве и продаже
в сеть розничной торговли высококачественной хлебобулочной
продукции. Мы дорожим качеством нашего товара и нашими отношениями с покупателями и поставщиками. Мы рассматриваем
наших работников как наиболее решающий ресурс, и заботится об
их профессионализме и благосостоянии.
Рис. 5.18. Формулировка миссии предприятия «Свежая выпечка»
Цели предприятия. Формулировка целей предприятия представлена на рис. 5.19.
Цели предприятия «Свежая выпечка»
1. Компания будет прилагать усилия для увеличения рынка и рентабельности.
2. Компания станет рыночным лидером в уровне обслуживания покупателей.
3. Компания станет инновационной в использовании технологий для
опережения конкурентов и выпуска на рынок новой продукции.
4. Компания будет бережливо использовать свой ресурс, необходимый для достижения ее высшей цели.
Рис. 5.19. Формулировка целей предприятия
Конкурентная стратегия. Определяя свою конкурентную стратегию, – метод, при помощи которого будет выполняться миссия, и достигаться поставленная цель, предприятие предпочло одну из трех
потенциально успешных базовых стратегий - «Абсолютное лидерство
в издержках».
Ключевые факторы успеха. Компания «Свежая выпечка» наметило перспективы улучшения своей конкурентной позиции, как это
показано на рис. 5.20. Дело не в том, может или не может предприятие в настоящее время реализовать эти факторы. Задача заключается
в определении факторов, дающих ключ к успеху в конкуренции.
227
Ключевые факторы успеха предприятия «Свежая выпечка»
1. КФУ, связанные с организацией производства:
низкие издержки производства;
пооперационное планирование, учет и контроль хода производства;
высокое качество производимых товаров.
2. КФУ, основанные на маркетинге:
организованная распределительная сеть, гибкость и простота размещения заказа и получения товаров клиентами,
качественная и быстрая доставка продукции клиентам;
применение технологии мобильной коммерции;
маркированная, удобная тара и упаковка, обеспечивающая считывание нанесенных компанией кодов.
3. КФУ, связанные с организацией и управлением:
наличие эффективной и надежной информационной системы;
непрерывное оптимальное планирование, синхронизированное с поступлением электронных заказов в реальном времени, распространяющееся на прокручиваемый горизонт времени;
гибкое динамическое управление производственными операциями,
основанное на подробных электронных данных о продукте;
управление отношениями с клиентами и конечными потребителями
продукции, CRM;
оптимизация и автоматизация логистики, с применением технологии «канбан», беспроводных устройств формирования первичных
данных.
Рис. 5.20. Формулировка ключевых факторов успеха
Рассмотренные факторы подразумевают применение компанией
четырех характерных современных методов, таких как электронная
информационная связь с клиентами, мобильные технологии, динамическое планирование, маркировка тары и продукции для машинного
считывания. Эти методы нуждаются в дальнейшей конкретизации с
учетом специфики компании. Например, уточненный метод CRM,
может выглядеть, как это представлено на рис. 5.21.
228
Цель CRM
x Привлечение новых покупателей
x Удержание существующих клиентов
Критерии оценки эффекивности CRM
x Стабильность обращений клиентов и повторные продажи
x Перекрестные продажи (приобретение дополнительных товаров)
x Увеличение покупок
x Рост числа покупок по рекомендации
x Повышение интереса клиентов к деятельности компании (участие в опросах,
высказывание пожеланий, посещение открытых мероприятий и пр)
Разработка новой
продукции
Программы CRM
x Продажи товаров
x Работа по претензиям
x Реклама новых и существующих товаров по клиентской базе
x Опрос клиентов
x Анализ поведения клиентов
Необходимый уровень подробности данных
x Детализация по клиентам
Инициализация
Данные заявок
Прием заказов
Маркетинг и CRM
Внедрение
Данные о потребности
График
Клиентоориентированное
планирование
Данные продаж
Производство
Передача
Заявки
График
Получение
Склад
Данные опроса
Претензии
Реклама
Перевозка
Доставка
Получение
Продажи
в локальной и
мобильных ТТ
Реализация
Рис. 5.21. Модель CRM-предприятия «Свежая выпечка»
Клиент
5.3.3. Планирование информационной системы
Планирование информационной системы «Свежая выпечка», выполняемое практически параллельно с планированием самой компании ее владельцем, осуществлялось таким образом, чтобы предприятие, реализуя принятую им конкурентную стратегию и критические
факторы успеха, могло разрешить имеющиеся проблемы, достичь поставленных целей и выполнить миссию, определенную стратегическим планом.
Трудовые ресурсы. Будущие трудовые ресурсы и их организация
предприятия «Свежая выпечка» представлены на рис. 5.22. Как можно увидеть из сравнения новая организация практически совпадает с
текущим состоянием. Исключение составляет только введенная
должность менеджера, выполняющего функцию управления отношениями с клиентами. При этом, роль управления производством на
предприятии отводится мастеру, а управление всеми отношениями с
клиентами передаются соответствующему менеджеру.
Директор
Начальник цеха
Бухгплтер
Бригада
доставки 3
Бригада
доставки 1
Грузчик
Производствен
ная бригада 3
Ночная смена
Производствен
ная бригада 2
Ночная смена
Производствен
ная бригада 1
Дневная смена
Бригада
доставки 2
Менеджер отношений с
клиентами
Мастер
Пекарькондитер 2
Пекарь 3
Пекарь 5
Водитель 1
Водитель 2
Водитель 3
Пекарькондитер 1
Пекарь 4
Пекарь 6
Экспидитор
1
Экспедитор
2
Экспедитор
3
Рис. 5.22. Структура трудовых ресурсов предприятия «Свежая выпечка»
230
Ручные и автоматизированные данные. Типы сущностей будущей информационной системы или шаблоны ручных и автоматизированных данных – это основные категории данных о людях, предметах, документах, местах, которыми оперирует организация. Для выполнения принятой целевой установки предприятие «Свежая выпечка» должно оперировать данными об объектах, опись которых представлена в табл. 5.4.
Таблица 5.4
Типы будущих сущностей
Тип сущности
АКТ О ПРИЕМКЕ
ТОВАРОВ
АКТ О СПИСАНИИ
ТОВАРОВ
БРИГАДА ДОСТАВКИ
ВОЗВРАТНАЯ
ТРАНСПОРТНАЯ
ТАРА (ЛОТКИ)
Описание
Применяется для оформления приемки товаров
по качеству, количеству, массе и комплектности
Применяется при оформлении возникающей
порчи, потери качества товаров.
Наименьшая организационная единица, осуществляющая транспортировку продукции и
ответственность за ее сохранность
Лотки установленного размера и формы, имеющие идентификационный номер известную
вместимость для каждого товара (тарный канбан)
Закрепление производственной бригады за
производственной сменой
Наименование производственной роли
Применяется для учета выполнения заказов покупателей, принятых к исполнению
ГРАФИК ПРОИЗВОДСТВЕННОЙ БРИГАДЫ
ДОЛЖНОСТЬ
ЖУРНАЛ УЧЕТА ВЫПОЛНЕНИЯ ЗАКАЗОВ
ПОКУПАТЕЛЕЙ
ЖУРНАЛ УЧЕТА
Применяется для учета движения и остатков
ТОВАРОВ НА СКЛАДЕ товаров и тары на складе (в кладовой)
ЗАДАНИЕ НА СМЕНУ Документ, определяющий виды продукции и ее
количество, которое необходимо произвести за
смену
ЗАКАЗ
Запрос покупателя/потребителя на изготовление поставку определенной продукции в определенном количестве и конкретные сроки
231
Продолжение табл. 5.4
ЗАЯВКА
Запрос предприятия на поставку ему поставщиками определенной продукции в определенном
количестве и конкретные сроки
КЛИЕНТЫ
Предприятия розничной торговли, заказывающие, приобретающие и принимающие продукцию предприятия для реализации
ЛОТ ДОСТАВКИ
Идентифицируемая транспортировочная стойка, загруженная лотками с продукцией известного наименования и количества, предназначенный для реализации (канбан)
МАРШРУТ
Путь следования транспортного средства с продукцией и закрепленные за ним прилегающие
точки розничной торговли, являющиеся клиентами предприятия
МЕСТОНАХОЖДЕНИЕ Место, в котором работники предприятия выполняет ту или иную бизнес функцию предприятия.
МЕСТОПОЛОЖЕНИЕ
Географическое место, определяемое почтовым
адресом
НАКЛАДНАЯ НА
Применяется для учета движения товарноВНУТРЕННЕЕ ПЕРЕматериальных ценностей (товара, тары) внутри
МЕЩЕНИЕ ТОВАРА
организации, между структурными подразделениям или материально ответственными лицами
ОБОРУДОВАНИЕ
Совокупность устройств, обеспечивающих работу предприятия
ПЕЧЬ
Устройство для выпечки изделий из теста
ХЛЕБОПЕКАРНАЯ
ТЕСТОЗАКАТОЧНАЯ
Машина для придания тестовым заготовкам
МАШИНА
цилиндрической формы
ТЕСТОМЕСИЛЬНАЯ
Устройство для замеса теста из сырья и его выМАШИНА
держки
МАШИНА
Устройство для взбивания мягкого теста, слиВЗБИВАЛЬНАЯ
вок, крема, мусса и т. п.
МОРОЗИЛЬНЫЙ ЛАРЬ Устройство для долговременного хранения
скоропортящейся продукции
МУКОПРОСЕИВАТЕЛЬ Устройство для рыхления и отделения посторонних примесей из муки
232
Продолжение табл. 5.4
РАССТОЙКА
Устройство для контролируемого брожения теста перед выпечкой
ОПЕРАТИВНЫЙ
Производственное расписание, определяющее
ГРАФИК
время начала и окончания прохождения каждой
стадии производства каждой изготавливаемой
партии изделий
ПАРТИЯ
Изделия или полуфабрикат, изготавливаемые
из единовременно подготовленной порции исходного сырья (тесто, начинка, кремовый заполнитель и т.п.)
ПОСТАВЩИК
Предприятия, осуществляющие поставку сырья
и упаковки
ПРЕТЕНЗИЯ
Претензия, предъявленная клиентом по качеству товара, его количеству и срокам поставки
ПРОДУКЦИЯ
Хлебобулочные изделия, включающие булочки,
торты, пирожные, пироги, рулеты, сухарики и
т.п.
ПРОИЗВОДСТВЕННАЯ Наименьшая организационная единица, осуБРИГАДА
ществляющая производство, и несущая ответственность
ПРОИЗВОДСТВЕННАЯ Операция изготовления изделия, используемая
ОПЕРАЦИЯ
на данной стадии производства
ПРОИЗВОДСТВЕННАЯ Идентифицируемый непрерывный отрезок вреСМЕНА
мени внутри суток
РАБОТНИК
Лицо, связанное с предприятием договором
найма
РАСХОДНОПрименяется для оформления отпуска товаров
ПРИХОДНАЯ
на лотки, продавцам с тележек, разносов и т.п.,
НАКЛАДНАЯ
на которые не составляются товарные отчеты
РЕЙС
Поездка автотранспорта, загруженного продукАВТОТРАНСПОРТА
цией для доставки ее клиентам, одного маршрута
РЕЦЕПТУРА
Сведения о качественном и количественном составе компонент, а также о последовательности
операций, необходимых для изготовления
определенного количества продукции
233
Окончание табл. 5.4
СКЛАДЫ
СТАДИЯ
ПРОИЗВОДСТВА
СТРОКА СПИСКА
ДОСТАВКИ
СЫРЬЕ
ТЕХНОЛОГИЧЕСКАЯ
ОСНАСТКА
ТЕХНОЛОГИЯ
ТОВАРНАЯ
НАКЛАДНАЯ
ТРАНСПОРТНЫЕ
СРЕДСТВА
ТРУДОУСТРОЙСТВО
УПАКОВКА
УЧАСТОК
ПРОИЗВОДСТВА
ЦЕНА
ЧЛЕН БРИГАДЫ
ШТАТНОЕ
РАСПИСАНИЕ
ЭКИПАЖ
Специальное помещение или определенное место для размещения и хранения сырья, упаковки и готовой продукции. Различают склад сырья и материалов и склад готовой продукции
Каждый шаг в направлении изготовления продукции, характеризующийся схожестью операций и использование схожего оборудования
(например, вымес, выпечка, расстойка и т.п.)
Наименование и количество товара, предназначенного для доставки одному заказчику за один
рейс
Мука, маргарин, дрожжи, молоко сгущенное,
специи, масло, соль, сахар, яйца изюм, фарш и
т.п.
Противни (подовые листы), формы для выпечки, шприцы и т. п.
Описание последовательности операций над
используемым сырьем, приводящих к продукту-результату (промежуточному, полуфабрикату, конечному продукту)
Применяется для оформления продажи (отпуска) товарно-материальных ценностей сторонней организации.
Крытые грузовые автомобили малой грузоподъемности, приспособленные для перевоза
продукции помещенной в лотки
Закрепление и открепление работника предприятия за имеющейся штатной единицей
Контейнеры, коробки, подложки и т.п.
Часть технологической линии, специализирующаяся на выполнении набора определенных
стадий технологии производства
Стоимость единицы продукта предприятия
Закрепление штатной единицы за бригадой
Список должностей предприятия
Транспортная бригада, закрепленная за транспортным средством
234
Эти объекты данных во взаимосвязанном виде, более похожем на
шаблон автоматизированных данных, представленном с использованием обозначений стандарта IDEF1X, изображены на рис. 5.23 в виде
контекстной модели данных предприятия. Эта модель, не ставя своей
целью отражения детальных подробностей предприятия, уточняет
понимание масштаба данных, которые необходимо использовать
предприятию, и является шаблоном для дальнейшей разработки.
Функции предприятия. Функции предприятия отличаются от организационных блоков. Одна функция может быть назначена нескольким организационным блокам. Вполне понятно, что процесс
продолжения декомпозиции некоторой функции в итоге приводит к
набору примитивных функций, каждая из которых закрепляется за
отдельным работником. Это позволяет также закрепить полную персональную ответственность за отдельными работниками. Владелец
компании «Свежая выпечка» разработал и представил набор функций, часть из которых он предполагает автоматизировать при помощи
создаваемой информационной системы (рис. 5.24).
Планирование предприятия
Разработка новой продукции
Производство продукции
Производственное планирование
Получение сырья со склада
Изготовление продукции
Управление и диспетчеризация производства
Передача выпущенной продукции на склад
Маркетинг, продажи и CRM
Реализация продукции с доставкой
Реализация продукции на месте
Инициализация разработки новой продукции
Управление отношениями с клиентами
Управление сырьем и материалами
Управление финансами и бухгалтерский учет
Рис. 5.24. Набор планируемых функций предприятия
235
Рис. 5.23. Контекстная модель данных предприятия «Свежая выпечка»
Далее владелец компании продолжил декомпозицию этих функций
до уровня примитивных. Некоторые из этих декомпозиций такие как
«Управление сырьем и материалами» (Управление запасами), «Производство продукции», «Маркетинг, продажи и CRM» представлены
соответственно на рис. 5.25–5.27.
Управлениесырьеми
материалами
Определениеуровня
минимальнодопустимого
запасаиповторногозаказа
Составлениезаявки
Размещениезаявки
Получениесырья
Рис. 5.25. Декомпозиция функции
«Управления сырьем и материалами»
Функциональные декомпозиции рис. 5.25–5.27 не требуют особых
пояснений. Исключение составляет примитивная функция «Прием
заказов», которую владелец компании определил как подфункцию
функции «Производство продукции». Предприятие включило ее в
область производства, так как намеревается полностью автоматизировать ее, исключив работу по приему заказов из состава ручных
операций. Это вовсе не означает, что функция «Маркетинг, продажи
и CRM» не имеет отношения к заказам клиентов. Данные о поступивших заказах просто воспринимаются маркетингом из системы при
выполнении закрепленных за ним функций. Противоположное решение, возможно, было бы также справедливым.
Более комплексные функциональные модели предприятия, определяющие его деятельность во взаимосвязи функций, их входов, выходов и закрепленного за ними ресурса не всегда создаются на этапе
планирования информационной системы. Однако такие модели позволяют существенно улучшить качество определения функций предприятия, так как дают возможность рассмотреть не только отношение
иерархического вхождения функций, а также интегрировано показать
отношение потока функций, отношения между функциями, персоналом, предметами деятельности и ресурсами. Существующий стан237
238
Товарное
оформление
Выпечка
Расстойка сырых
изделий
Изготовление
изделий
Расстойка
Разделка теста
Приготовление
смеси и вымес
Изготовление
полуфабрикатов
Подготовка сырья
Перепланирование
оперативного
графика при
отклонении
процесса
Сравнение
фактического хода
производства с
запланированным
Фиксация рабочим
момента начала и
окончания
операции
Выдача на рабочие
места информации
о планируем ходе
выполнения
операций
Отслеживание
плана по текущему
времени
Разработка
оперативного планграфика
Оперативное
планирование в
прокручивающемся
горизонте
Прием заказов
Текущее
планирование
производства
Передача готовой
продукции на
склад
Управление и
диспетчеризация
производства
Изготовление
продукции
Получение сырья
со склада
Планирование
производственное
дартный метод функционального моделирования IFEF0 и соответствующие CASE средства позволяют автоматизировать этот процесс,
существенно снижая затраты труда и времени на его проведение. Поэтому если функциональная модель предприятия существует, то она
может быть рассмотрена как часть требований фазы планирования,
устанавливающих контекст и шаблоны процессов будущей информационной системы.
Производство
продукции
Рис. 5.26. Декомпозиция функции «Производства продукции»
Анализ
поведения
клиентов
Опрос
клиентов
Реклама новой
продукции
Работа по
претензиям
Прием
претензий
Отслеживание
заказов
Передача
выручки и
тары
Управление
отношениями с
клиентами
Инициирование разработки
новой
продукции
Реализация на
месте
Получение
выручки,
прием тары
Отпуск
продукции
Доставка
продукции
Загрузка товара
в транспорт
Планирование
доставки
Реализация с
доставкой
Маркетинг,
продажи и CRM
Рис. 5.27. Декомпозиция функции «Маркетинга, продажи и CRM»
Учитывая вышеизложенное преимущество применения этих моделей, владелец компании «Свежая выпечка» разработал функциональные модели предприятия на фазе планирования, часть из которых «Производство продукции» и «Маркетинг, продажи и CRM», представлены на рис. 5.28–5.31.
Функциональная модель «Производство продукции». Модель
рис. 5.28 в укрупненном виде представляет цикл производства продукции от получения сырья со склада до сдачи готовой продукции на
склад блоки (2, 3 и 5). Блок 1 осуществляет разработку оперативного
рабочего графика на основе поступающих заказов и данных о продажах предприятия. Разработанный рабочий план поступает в блок 4,
который осуществляет управление и диспетчеризацию производственного процесса. Отслеживая рабочий оперативный план по текущему времени, блок 4 выдает на участки технологического процесса
электронное визуальное представление текущей части рабочего плана
239
для производственной бригады. Производственная бригада выполняет операции технологического процесса. Данные учета о выполнении
каждой технологической операции в блоках 2, 3 и 5 в электронном
виде поступают в блок 4 в реальном масштабе времени. Блок 4 осуществляет сравнение планируемого времени выполнения операций с
фактическим. В случае большого отклонения факта от плана он осуществляет перепланирование оперативного рабочего графика и далее
продолжает осуществлять управление процессом, но уже согласно
новому состоянию рабочего графика.
Рис. 5.28. Модель функции «Производство продукции»
Функциональная модель «Производственное планирование»
рис. 5.29, являясь декомпозицией блока 1 рис. 5.28, показывает этапы
процесса планирования производства. Здесь представлена взаимосвязь трех этапов планирования, изображенных в виде отдельных
блоков деятельности (блоки 1.1, 1.3, 1.4). Определена взаимосвязь
блока оперативного планирования в прокручивающемся горизонте
(блок 1.3) с данными принятыми заявок и взаимосвязь блока разработки рабочего оперативного графика (блок 1.4) с данными оперативного планирования и данными статистического прогноза.
Функциональная модель «Изготовление продукции» рис. 5.30,
являясь декомпозицией блока 3 рис. 5.28, представляет стадии произ240
водственного процесса. Здесь показано поступление электронного
визуального представления текущей части рабочего оперативного
графика на участки производства. Электронной представление рабочего графика на участке производства доставляет в визуальном виде
производственной бригаде очередное элементарное задание. Это задание одержит в себе все расчетные данные об используемых материалах, включая их количество, а также нормативное время начала и
окончания выполнения данной стадии производства. Данные учета, в
основном, определяют фактическое время начала и окончания выполнения каждого задания. Эти данные формируются в полуавтоматическом режиме при помощи средств автоматизации формирования
первичных данных.
Рис. 5.29. Модель функции «Производственное планирование»
Функциональная модель «Управление и диспетчеризация» рис.
5.31, являясь декомпозицией блока 4 рис. 5.28, определяет деятельность, связанную с исполнение рабочего оперативного графика. Здесь
блок 1 осуществляет отслеживание операций графика по текущему
времени. Блок 2 выдает соответствующие им данные на рабочие места в электронном представлении. Блок 3 принимает данные об исполнении операций. Блок 4 отслеживает и сравнивает запланирован241
ное и фактическое время выполнения операций и в случае недопустимого отклонения факта от плана запускает блок 5 на выполнение
перепланирования рабочего графика. Действия, определяемые данной
моделью, выполняются в автоматическом режиме.
Рис. 5.30. Модель функции «Изготовление продукции»
Рис. 5.31. Модель функции «Управление и диспетчеризация»
242
Будущие подсистемы информационной системы. Осуществляя
далее переход от функций компании к набору планируемых подсистем
информационной системы, выполняющих роль программных средств
автоматизации этих функций, владелец компании «Свежая выпечка»
определил набор планируемых подсистем и задач информационной системы, как это показано в табл. 5.5. Набор этих подсистем – это те конкретные части программного обеспечения информационной системы
компании, которые должны быть физически созданы, отлажены, проверены и установлены в качестве приложений на вычислительной системе предприятия. Для каждой из этих будущих подсистем и задач может
быть определена трудоемкость, стоимость разработки, приоритет в
очереди физической реализации и внедрения в компании.
Таблица 5.5
Подсистемы и задачи информационной системы
Подсистема, задача
Обработка транзакций
производства и продаж
Получение сырья
со склада
Краткая характеристика
Выполнение рутинных операций предприятия,
осуществление их регистрацию и учета
Выдача сырья и материалов со склада в соответствие с потребностями плана производства на
смену
Контроль фактического
Контроль фактического времени начала и оконначала и окончания
чания операции. Осуществляется нажатием разаданной работнику
бочим соответствующе кнопки на экране сеноперации
сорного дисплея
Выпуск готовой
Учет продукции на выходе технологической
продукции
линии для каждой выпускаемой партии и размещение ее в идентифицируемых лотках
Прием готовой продукции Передача лотков с готовой продукцией на склад,
на склад
учет идентификатора лотка, отправителя и времени (внутренняя передача)
Отпуск готовой
Выдача лотков с продукцией со склада, учет
продукции со склада
идентификатора лотка, времени и получателя
(внутренняя передача)
Прием и обработка
Прием поступающих интернет заказов в предезаказов
лах прокручивающегося горизонта, размещение
заказа в предварительный оперативный график
243
Окончание табл. 5.5
Реализация продукции с доставкой
Реализация продукции на месте
Управление ресурсами
Управление изделиями
Управление
возвратной тарой
Управление
транспортом
Управление
технологическим
оборудованием
Управление
персоналом
Управление
процессами
Планирование
производства
Планирование
доставки
Оперативное
планирование
производства
Управление
запасами сырья и
материалов
Доставка и реализация продукции мобильным агентом
Реализация продукции в стационарной торговой точке предприятия
Развитие ресурсной базы, ее учет, поддержка рабочего состояния, списание
Разработка и ввод новых изделий, рецептуры, учет
объема выпуска и потребления продукции, анализ
доходности, цены и себестоимости
Приобретение, списание тары (лотков). Присвоение
идентификационных номеров для вновь приобретаемых лотков. Контроль оборота тары
Приобретение, эксплуатация, списание транспортных
средств
Приобретение, обслуживание и списание технологичес5кого оборудования
Наем/увольнение. Квалификация, ставки оплаты труда. Закрепление персонала за бригадами и автотранспортом
Планирование хода процессов на будущие периоды,
контроль, анализ, принятие и реализация решений
Разработка годовых, квартальных и месячных планов
Разработка оптимального графика доставки продукции в торговые точки
Разработка оперативного графика производства
1. Определение уровня минимального запаса, уровня
повторного заказа, закупочных цен и поставщиков
2. Составление подача заявки
3. Прием поступившего сырья и материалов
Управление и
Информирование работника о текущей операции.
диспетчеризация
Корректировка оперативного графика при отклонепроизводства
нии фактического хода производственного процесса
от запланированного
Маркетинг и управ- Управление продажами, отслеживание выполнения
ление отношениями заказов, прием претензий, работа по претензиям, рес клиентами
клама, опрос, анализ поведения клиентов
244
Обработка транзакций производства и продаж
Получение сырья со склада
Контроль фактического начала
и окончания операции
Прием готовой продукции на склад
Отпуск готовой продукции со склада
Прием и обработка заказов
Реализация продукции с доставкой
Реализация продукции на месте
Управление ресурсами
Управление изделиями
Управление возвратной тарой
Управление транспортом
Управление технологическим оборудованием
Управление персоналом
Управление процессами
Текущее планирование производства
Планирование доставки
Оперативное планирование производства
Управление запасами сырья и материалов
Управление и диспетчеризация производства
Маркетинг и управление отношениями
с клиентами
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Бережливое использование ресурса
Стать инновационной
Подсистема, задача
Стать лидером
Увеличение
рентабельности
Цели компании
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Х
Рис. 5.32. Матрица «Подсистема – цели»
Разработка и анализ матриц планирования. Владелец компании
также провел разработку и анализ матриц планирования, обеспечив
тем самым согласованность решений, принятых на этапах планирования, и кластеризацию по сходству элементов системы. Пример одной
из таких матриц приведен на рис. 5.32. Использование на предшествующем шаге планирования метода функционального моделирова245
ния позволило существенно сократить количество нарушений согласованности решений, допущенных на этапах планирования, и соответственно выявленных противоречий в ходе анализа матриц.
Матрица «подсистемы-цели», представленная на рис. 5.32, показывает, как подсистемы и задачи будущей информационной системы
способствуют достижению целей компании. Здесь можно отметить,
что большинство из предлагаемых подсистем и задач направлено на
расширение рынка, повышение рентабельности, увеличение функциональной и операционной эффективности. В то же самое время подсистемы, автоматизирующие процесс и в значительной мере устраняющие участие человека, направлены на перевод компании в разряд
инновационной и рыночного лидера.
Ключевые термины
Анализ цепочки приращения
стоимости
Восходящее планирование
Кластеризация по сходству
Ключевые факторы успеха
Конкурентная стратегия
Корпоративное стратегическое
планирование
Нисходящее планирование
Планирование информационных систем
Поэтапное выполнение
Приростное обязательство
Миссия
Цель
Примитивная функция
Контрольные вопросы
1. Дайте определение каждого из представленных выше ключевых
терминов.
2. Сравните следующие термины:
а) формулировка миссии, цели и конкурентная стратегия;
б) корпоративное стратегическое планирование, планирование информационных систем;
в) недорогой изготовитель, дифференциация продукта, концентрация на товаре или нише;
246
г) объект данных, информационная система.
3. Опишите процесс идентификации и выбора проекта.
4. Опишите несколько критериев оценки проектов.
5. Опишите анализ по цепочке приращения стоимости, а также применение этого метода в организации для оценки и сравнения проектов.
6. Обсудите несколько факторов, свидетельствующих о необходимости улучшения планировании информационных систем сегодня.
7. Опишите шаги корпоративного стратегического планирования.
8. Назовите три общие конкурентные стратегии.
9. Опишите смысл планирования информационных систем и шаги,
связанные с эти процессом.
10. Перечислите и опишите преимущества нисходящего планирования перед другими подходами планирования.
11. Кратко опишите девять матриц планирования, используемых для
планирования информационных систем, идентификации и выбора проектов.
12. Назовите источники поступления предложений на разработку
информационной системы.
13. Охарактеризуйте зависимость данных и процедур от изменений, происходящих в компании.
Глава 6. АНАЛИЗ СИСТЕМ
Анализ является фазой жизненного цикла разработки систем, когда
глубоко осмысливается потребность системных изменений. Фаза анализа в жизненном цикле занимает место между предшествующей ей
фазой планирования информационной системы и следующей за ней
фазой проектирования системы. Таким образом, получая на своем
входе результаты планирования системы, фаза анализа системы должна выработать и представить на своем выходе все спецификации и модели, достаточные для проведения работ проектирования будущей системы. В противоположность фазе анализа, которая является практически не зависящей от технологий реализации информационной системы, фаза проектирования или дизайна, наоборот, является технологически зависимой фазой и выполняется с учетом произведенного выбора технологических сред и платформ реализации будущей информационной системы. Вышеприведенное уточнение является попыткой
повысить определенность толкования ряда терминов в рамках данной
работы. Это вызвано, прежде всего, существующей еще некоторой неопределенностью и размытостью границ между этапами, порожденной
многообразием существующих сегодня методологий разработки.
Анализ систем связан со значительным количеством усилий и затрат, и поэтому проводится только после того как руководство решит,
что рассматриваемый проект разработки системы имеет свои плюсы и
должен осуществляться этот его этап. Группа анализа не должна воспринимать процесс анализа как само собой разумеющееся и не пытаться ускорить его прохождение. Большинство профессионалов согласились бы, что многие ошибки в разработанных системах являются
прямым следствием неадекватно приложенных усилий на этапах анализа и проектирования жизненного цикла. Так как анализ является
большим и сложным процессом, его часто разделяют на две части,
чтобы сделать его процесс более легким в понимании.
x Определение требований. Эта деятельность, в основном, связана
со сбором фактов.
248
x Структурирование требований. Эта деятельность создает исчерпывающее и ясное описание текущих бизнес операций и новых сервисов по обработке информации.
Цель анализа заключается в определении информации и сервисов
информационной обработки, необходимой для поддержки выбранных
целей и функций организации. Сбор информации называется определением требований. Деятельность определения требований использует
специальные методы сбора фактов для изучения текущей системы организации, которую будет поддерживать замещающая система, а также требований пользователей или их ожиданий от замещающей системы.
Однако простой сбор и обобщение существующих фактов, информации о состоянии предприятия, ожиданий и мнений не могут являться основным механизмом формирования нового в замещающей системе. Основным источником новой системы все же остается реинжиниринг бизнес-процессов (BPR). В отличие от постепенных
улучшений, которые движут проекты разработки многих систем, BPR
приводит к результату радикальной реконструкции процессов, поддерживаемых разрабатываемой информационной системой.
Информация о текущих операциях и требованиях для замещающей
системы должна быть каким-то образом организована для анализа и
проектирования. Организация, или структурирование, требований системы приводит к результату в виде моделей, схем и описаний, которые могут быть подвергнуты анализу для определения недостатков,
неэффективности, пропущенных элементов и логических компонентов
бизнес операций и информационных систем. Наряду с требованиями
пользователей они используются для определения стратегии для замещающей системы
Результаты определения требований могут быть структурированы в
соответствии со следующими неотъемлемыми компонентами текущей
и замещающей информационной системы.
x Процессы. Последовательность движения и хранения данных, а
также операции обработки в системе.
249
x Данные. Природная структура данных независимо от того, как и
когда они обрабатываются.
Эти компоненты могут быть изображены при помощи диаграмм
потоков данных и моделей сущность-связь. Рассматриваемые в главе
тематические примеры иллюстрируют указанные модели, описывающие новую систему. Примеры также иллюстрируют, как диаграммы и
модели для каждого из этих видов представления системы связаны
друг с другом, чтобы сформировать совместимое и тщательно структурированное описание предлагаемой системы.
6.1. Структурирование требований процессов системы
Этот раздел сосредотачивает внимание на одном средстве, которое
используется для связанного представления информации, полученной
в ходе определения требований, – диаграммах потока данных. Диаграммы потока данных позволяют нам моделировать движение данных через информационную систему, отношения между потоками
данных и поступление данных в конкретные места для хранения.
Диаграммы потока данных также показывают процессы, которые изменяют или преобразуют данные. Поскольку диаграммы потока данных сосредоточиваются на перемещении данных между процессами,
эти диаграммы называются моделями процессов.
Как следует из названия, диаграмма потока данных представляет
собой графическое средство, которое позволяет аналитикам изобразить поток данных в информационной системе. Система может быть
физической или логической, ручной или автоматизированной. В этом
разделе рассматривается, как создать и проверить диаграммы потоков
данных. В нем представляются базовые символы, используемые в таких диаграммах и набор правил, управляющих составлением диаграмм. Здесь также рассматривается то, что надо и чего не надо делать при создании диаграмм потока данных. В нем также представлены два важных понятия, связанные с диаграммами потоков данных,
балансировка и декомпозиция.
250
6.1.1. Моделирование процесса
Моделирование процесса касается графического представления
функций или процессов, которые позволяют получать, обрабатывать,
хранить и распространять данные между системой и ее окружением, а
также между компонентами внутри системы. Распространенной формой модели процесса являются диаграммы потока данных (Data Flow
Diagrams, DFD).
На протяжении многих лет, для моделирования процесса было
разработано несколько различных средств. Диаграммы потока данных – это традиционный метод моделирования процессов в анализе и
дизайне систем, наиболее часто используемый в настоящее время.
Моделирование процессов систем в структурном анализе. Как
было уже рассмотрено, фаза анализа в жизненном цикле разработки
информационных систем включает в себя: определение требований и
структурирование требований. Группа анализа приступает к фазе
структурирования с обилием информации, собранной во время фазы
определения требований. В течение выполнения структурирования
требований члены группы должны организовать эту информацию в
осмысленное представления информационной системы, существующей в настоящее время, и желаемых требований к замещающей системе. В дополнение к моделированию обрабатывающих элементов
информационной системы и преобразованию данных в системе необходимым является также моделирование структуры данных информационной системы. Совместно модели всех компонентов информационной системы обеспечивают тщательную спецификацию информационной системы и с помощью соответствующих поддерживающих средств также обеспечивают основу для автоматической генерации многих работающих компонентов информационной системы.
Ожидаемые результаты и итоги. В структурном анализе основные ожидаемые результаты, полученные путем моделирования процесса, представляют собой набор взаимосвязанных и согласованных
DFD. Табл. 6.1 дает более подробный список ожидаемых результатов,
251
получаемых в результате использования DFD, для изучения и документирования процессов системы. Во-первых, контекстная диаграмма показывает широту охвата системы, указывая, какие элементы
находятся внутри, а какие вне системы. Во-вторых, диаграммы потоков данных системы, определяющие процессы перемещения и преобразования данных, воспринимающие входы и создающие выходы,
разрабатываются достаточно подробно, чтобы понять нынешнюю текущую систему и, в конечном счете, определить, как преобразовать
существующую систему в замещающую. Наконец, данные для всех
объектов, входящих в состав всех диаграмм, включаются в словарь
проекта или репозиторий CASE. Эта логическая последовательность
результатов позволяет понять существующую систему. Далее можно
подвести итоги этой системы, представив ее существенные элементы,
чтобы показать, как новая система должна соответствовать требованиям обработки информации, выявленным в ходе определения требований. Необходимо помнить, что ожидаемые результаты моделирования процесса просто излагают то, что было выявлено во время
определения требований. На более поздних стадиях жизненного цикла разработки систем группа проекта будет принимать решения о
том, как конкретно новая система будет доставлять эти новые требования, представляя свои решения в автоматизированных функциях и
в описаниях конкретных руководств. Так как определение требований и структурирование часто являются параллельными шагами DFD
эволюционируют от более общего к более подробному, по мере формирования лучшего понимания текущей и замещающей системы.
Таблица 6.1
Ожидаемые результаты моделирования процессов
1. Контекстная диаграмма потоков данных
2. Диаграммы потоков данных текущей и новой системы (адекватно
декомпозированных)
3. Полное описание каждого компонента диаграммы потока данных
252
Несмотря на то, что DFD остаются популярными инструментами
для моделирования процесса и позволяют значительно повысить производительность разработки программного обеспечения, они не используются во всех методологиях разработки системы. Некоторые
организации, такие как EDS (Electronic Data System), разработали
свои собственные диаграммы для моделирования процессов. Другие
организации полагаются на средства моделирования процессов, представленные в наборах средств CASE. Некоторые методологии, такие
как RAD и методологии объектно-ориентированного анализа и проектирования, вовсе не моделируют отдельно процессы.
DFD обеспечивают обозначения, а также иллюстрируют важные
понятия о движении данных между ручными и автоматическими шагами действий, и предлагают способ для изображения рабочего процесса в организации. DFD продолжают быть полезными для профессионалов по информационным системам в качестве средства, как для
анализа, так и коммуникации.
6.1.2. Составление диаграмм потока данных
Диаграммы потока данных являются многогранным средством составления схем. Использование только четырех символов позволяет
применять DFD, как для логического, так и физического представления информационных систем. DFD не так хороши, как блок-схемы
для изображения деталей физических систем (например, технологическая схема процесса). С другой стороны, блок-схемы, не очень полезны для изображения чисто логических информационных потоков.
В самом деле, блок-схемы были подвергнуты критике сторонниками
структурного анализа и проектирования, потому что они слишком
ориентированы на физическую природу объекта моделирования.
Символы составления блок-схем в основном представляют собой физическое вычислительное оборудование, такое как терминалы и
устройства постоянного хранения. Одним из постоянных аргументов
критики блок-схем систем является то, что чрезмерное увлечение та253
кими схемами, как правило, приводит к преждевременному проектированию физической системы. В соответствии с философией приростных обязательств жизненного цикла разработки систем для того,
чтобы сделать выбор технологий и принять решение о физических
характеристик информационной системы, требуется некоторое ожидание, пока не появится уверенность в том, что все функциональные
требования являются правильными и что они приняты пользователями и другими заинтересованными сторонами.
DFD не имеют ничего общего с этой проблемой преждевременного физического проектирования, потому что они не зависят ни от каких символов, представляющих определенное физическое вычислительное оборудование. Они также легче в использовании, чем блоксхемы, поскольку они применяют только четыре различных символа.
Определения и символы. Существует два различных стандартных набора DFD символов. Каждый набор состоит из четырех символов, которые представляют одно и то же: потоки данных, элементы
хранения данных, процессы и источники/приемники (или внешние
субъекты). Набор символов, используемый в этой книге, представлен
на рис. 6.1. Он был разработан Гейном и Сарсоном в 1979 г. Другой
похожий набор был разработан примерно в то же самое время Де
Марко и Йорданом.
Процесс
Элемент хранения
данных
Источник/Приемник
Поток данных
Рис. 6.1. Набор символов DFD
254
В обоих случаях в наборе присутствуют символы, называемые: поток данных, элемент хранения данных, процесс и источник/приемник.
Поток данных лучше всего следует понимать, как данные в движении, т.е. движение данных из одного места системы в другое. Поток данных мог бы представлять данные из формы заказа клиента или
платежного поручения банку. Он также мог бы представлять результаты запроса к базе данных, содержание печатного отчета или данные
компьютерной дисплейной формы ввода данных. Поток данных – это
данные, которые движутся вместе так, что он может состоять из множества отдельных элементов данных, которые генерируются в то же
время и которые текут вместе к общим местам назначения.
Элемент хранения данных – это данные находящиеся в покое.
Элемент хранения данных может представлять одно из многих различных физических мест нахождения данных. Например, папка для
файлов, один или более компьютерных файлов, база данных, таблица
базы данных или ноутбук. Для понимания движения и обработки
данных в системе не требуется знания физической конфигурации системы. Элемент хранения данных может содержать данные о клиентах, студентах, заказах клиентов, или счетах-фактурах поставщиков.
Процесс – это работа или действия, выполняемые над данными
для их превращения, хранения или распределения. При моделировании обработки данных системы не имеет значения, осуществляется
ли этот процесс вручную или с помощью компьютера.
Источник/приемник определяет место, откуда движутся данные
(происхождение), и место, куда они движутся (назначение). Источники/приемники иногда называют внешними объектами, потому что они
находятся за пределами системы. После обработки данные или информация покидает систему и переходит в другое место. Так как источники
и приемники находятся за пределами изучаемой системы, многие из
характеристик источников и приемников не представляют интереса для
аналитиков. В частности, не рассматривается следующее.
x Взаимодействие, которое происходит между источниками и
приемниками.
255
x Что делает с информацией источник или приемник и как он работает (то есть, источник или приемник является «черным ящиком»).
x Как управлять, или осуществлять ре-дизайн источника или
приемника, потому что с точки зрения изучаемой системы данные,
получаемые приемником, и данные, обеспечиваемые источником, являются фиксированными.
x Как обеспечить источники и приемники прямым доступом к
элементам хранения данных, потому что, как внешние агенты, они не
могут непосредственно осуществлять доступ или манипулировать
данными, хранимыми внутри системы; то есть, процессы внутри системы должны получать, или распространять данные между системой
и окружающей средой.
Символы, представленные на рис. 6.1, используются при составлении DFD следующим образом. Поток данных изображается в виде
стрелки. Стрелке дается имя, отражающее смысл данных, находящихся
в движении. Например, «Заказ клиента», «Квитанция об оплате» или
«Платежный документ». Название представляет собой совокупность
всех отдельных элементов данных, движущихся в рамках одного пакета, то есть, всех данных, движущихся вместе в то же самое время. Прямоугольник используется для обозначения источников/приемников и
имеет имя, которое определяет, что является внешним агентом, например, «Заказчик», «Кассир», или «Система управления запасами».
Символ для процесса – прямоугольник с закругленными углами.
Верхняя часть символа используется для указания номера процесса.
Внутри нижней части находится имя процесса, например, «Рассчитать оплату сверхурочных» или «Вычислить средний балл». Символ
для элемента хранения данных является прямоугольником с отсутствующей правой вертикальной стороной. На левом торце этого символа имеется прямоугольное поле, в котором указывается номер элемента хранения данных, а внутри основной части элемента хранения
указывается имя, отражающее смысл хранимых в этом элементе данных, например, «Принятые заказы», «Отложенные заказы», «Личные
данные студентов» и т.п.
256
Как отмечалось ранее, источники/приемники всегда находится вне
информационной системы, и определяют границы системы. Данные
должны быть получены за пределами системы из одного или нескольких источников. Система должна выработать информацию для
одного или более приемников (это соответствует принципам открытых систем, почти каждый информационная система является открытой системой). Если любая обработка данных происходит внутри источника/приемника, это не представляет интереса, так как эта обработка происходит за пределами системы, на которую составляется
диаграмма. Источник/приемник может представлять следующее.
x Другая организация или подразделение, отправляющее данные в
систему или получающее информацию от анализируемой системы
(например, поставщик или учебный отдел, в любом случае организация является внешней по отношению к изучаемой системе).
x Лицо внутри или за пределами бизнес-подразделения, поддерживаемого анализируемой системой, которое взаимодействует с системой (например, клиент или кредитный инспектор).
x Другая информационная система, с которой обменивается информацией анализируемая система.
Много раз те, кто только изучает как использовать DFD, попадают
в тупик с вопросом, является ли что-то источником/приемником или
процессом в системе. Эта дилемма имеет место чаще всего, когда потоки данных в системе пересекают границы офиса или отдела. В связи с этим некоторая обработка происходит в одном офисе, и обработанные данные перемещаются в другой офис, где происходит дополнительная обработка. Начинающие склонны идентифицировать второй офис как источник/приемник, чтобы подчеркнуть тот факт, что
данные были перенесены с одного физического места в другое
(рис. 6.2а). Тем не менее мы не должны быть обеспокоены тем, где
физически расположены данные. Мы больше заинтересованы в том,
как они движутся через систему, и как они обрабатываются. Если обработка данных в другом офисе может быть автоматизирована с помощью рассматриваемой системы или обработка данных может быть
257
предметом ре-дизайна, то тогда необходимо представлять второй
офис в виде одного или нескольких процессов, а не как источник/приемник (рис. 6.2б).
а)
б)
Рис. 6.2. Различия между источниками/приемниками и процессами:
а) Ошибочно созданная DFD, представляющая процесс
как источник/приемник;
б) DFD, показывающая правильное использование процесса
258
Пример разработки DFD. Иллюстрация использования DFD для
моделирования логики информационных потоков в системах осуществляется при помощи примера. Пример представляет собой небольшой фрагмент информационной системы предприятия «Свежая
выпечка». Фрагмент включает ту часть системы, которая принимает
заказы клиента на продукцию, передает их в производство, ведет учет
выпущенной продукции и сырья, использованного для изготовления
продукции по поступившим заказам. Назовем ее «Система заказов
пекарной продукции».
Информационная система, изображенная как DFD, представлена
на рис. 6.3. Высший уровень представления этой системы, показанный на рисунке, называется контекстной схемой или контекстной
диаграммой. Заметим, что эта контекстная диаграмма содержит только один процесс и четыре источника/приемника. В ней отсутствуют
элементы хранения данных и потоки данных. Единственный процесс,
обозначенный 0, представляет всю систему. Все контекстные диаграммы имеют только один процесс, обозначаемый 0. Источники/приемники представляют границы среды системы. Поскольку элементы хранения данных системы концептуально находятся внутри
одного процесса, то они не появляются на контекстной диаграмме.
Рис. 6.3. Контекстная диаграмма системы заказа пекарной продукции
259
Аналитик должен определить, какие процессы представлены одним процессом в контекстной диаграмме. Как можно видеть на рис.
6.4, в данном случае, он представляет четыре отдельных процесса.
Эти процессы соответствуют следующим действиям.
1. Получение данных от всех источников (например, процессы 1, 3).
2. Поддержка элементов хранения данных (например, процессы 2
и 3).
3. Формирование и распределение данных по различным приемникам (например, процесс 1 и процесс 4).
4. Описание на высоком уровне операций преобразования данных
(например, процесс 1).
Эти основные функции часто соответствуют деятельности, указываемой на главном меню системы. Мы видим, что система начинает с
заказа клиента, как это было в случае с контекстной диаграммы. В
первом процессе, помеченном 1, мы видим, что заказ клиента обрабатывается. В результате генерируется три потока данных: (1) производственное задание передается в цех, (2) заказ преобразуется в данные об используемом сырье и (3) квитанция для клиента генерируется процессом.
Рис. 6.4. Диаграмма уровня 0 системы заказа пекарной продукции
260
Обратим внимание, что источники/приемники в контекстной схеме
и в этой схеме являются теми же: клиент, цех, склад и менеджер предприятия. Эта диаграмма называется диаграммой уровня 0, потому что
она представляет собой первичные отдельные процессы в системе на
самом возможном высоком уровне. Каждый процесс имеет номер.
Два из потоков данных, генерируемых в первом процессе «Принять
и преобразовать заказ», идут к внешним источникам/приемникам, поэтому разработчику диаграммы больше не придется беспокоиться о
них. Он не должен быть обеспокоен тем, что происходит за пределами
рассматриваемой системы. Третий поток данных «Данные о сырье»
идет к другому процессу под номером 2 «Обновить данные о запасах
сырья». Выход этого процесса наименован «Отформатированные данные о сырье». Этот выход обновляет элемент хранения данных, имеющий имя «Запасы сырья». Так как на выполнение заказа изготовления продукции требуется определенное сырье в указанных количествах, то существующие записи о запасах этого сырья будут уменьшены на соответствующую величину операцией обновления. Ежедневные итоги уменьшения запасов сырья будут затем использованы как
вход в процесс 4 «Создать отчет для менеджера». Подобным образом
процесс «Учесть готовую продукцию» под номером 3, воспринимая
поток данных от внешнего источника «Склад», обновляет элемент
хранения данных «Готовая продукция». При поступлении данных о
приеме очередной партии выпущенной продукции на склад в указанном количестве элемент хранения данных будет увеличен на соответствующее значение. Затем «Ежедневные данные о выпущенной продукции будут использованы как вход процесса «Создать отчет для менеджера» под номером 4. Поток данных «Управленческий отчет», выходящий из процесса «Создать отчет для менеджера» с номером 4,
направляется к внешнему приемнику «Менеджер предприятия».
Рис. 6.4 иллюстрирует несколько важных понятий о движения информации. Рассмотрим поток данных «Данные о сырье», перемещающийся от процесса 1 к процессу 2. Мы знаем из диаграммы, что
процесс 1 производит этот поток данных, а процесс 2 получает его.
261
Тем не менее мы не знаем сроки во времени, когда этот поток данных
передается, как часто он производится, или какой объем данных при
этом отправляется. Таким образом, эта DFD скрывает многие физические характеристики описываемой системы. Мы знаем, однако, что
этот поток данных необходим процессу 2 и 1, и что процесс 1 обеспечивает эти необходимые данные.
Поток данных «Данные о сырье» также предполагает, что всякий
раз, когда процесс 1 производит его, процесс 2 должен быть готов его
принять. Таким образом, процессы 1 и 2 являются связанными друг с
другом. В отличие от этого, связь между процессом 2 и процессом 4
имеет другое свойство. Выход из процесса 2 «Отформатированные
данные о сырье» помещается в элемент хранения данных «Запасы
сырья», а затем позже, когда процесс 4 будет нуждаться в этих данных, он прочитает суммы «Ежедневное уменьшение запасов» из этого элемента хранения данных. В этом случае, процессы 2 и 4 развязаны путем размещения буфера элемента хранения данных между ними. Теперь, каждый из этих процессов может работать в своем собственном темпе, и процесс 4 не должен быть готовым принять ввод в
любое время. Кроме того, файл или таблица данных «Запасы сырья»
становится ресурсом данных, который мог бы потенциально использоваться и другими процессами для извлечения данных.
Правила диаграмм потока данных. При составлении DFD необходимо следовать набору правил. В отличие от самих диаграмм потока данных эти правила позволяют создателю DFD (или средству
CASE) оценить диаграмму на корректность. Эти правила приведены в
табл. 6.2.
В дополнение к правилам табл. 6.2, существуют еще два принципа
DFD, которые часто применяются.
1. Входы в процесс отличаются от выходов этого процесса. Причина состоит в том, что процессы, так как они имеют цель, как правило,
преобразуют входы в выходы, а не просто передают данные через себя
без какой-либо обработки.
262
Таблица 6.2
Правила составления диаграмм потока данных
Процесс:
1. Процесс не может иметь только выходы. Это бы создавало данные из
ничего. Если объект имеет только выходы, следовательно, должен быть и
источник.
2. Процесс не может иметь только входы (черная дыра). Если объект имеет только входы, то он должен быть приемником.
3. Процесс имеет имя в виде глагольной фразы.
Элемент хранения данных:
4. Данные не могут перемещаться непосредственно от одного элемента
хранения в другой элемент хранения. Данные должны быть перемещены
через процесс.
5. Данные не могут перемещаться непосредственно от внешнего источника в элемент хранения данных. Данные должны быть перемещены процессом, который получает данные от источника и помещает данные в элемент
хранения данных.
6. Данные не могут перемещаться непосредственно к внешнему приемнику из
элемента хранения данных. Данные должны быть перемещены процессом.
7. Элемент хранения данных имеет имя в виде фразы из существительных.
Источник/приемник:
8. Данные не могут перемещаться непосредственно от источника к приемнику. Они должны быть перемещены процессом, если данные имеют какое-либо отношение к нашей системе. В противном случае, поток данных
не отображается.
9. Источник/приемник имеет имя в виде фразы из существительных.
Поток данных:
10. Поток данных имеет только одно направление потока между двумя
символами. Он может течь в обоих направлениях между процессом и элементом хранения данных, чтобы показать, выполнение чтения перед обновлением. Последнее, как правило, указывается, однако, двумя отдельными стрелками, так как это происходит в разные моменты времени.
11. Развилка в потоке данных означает, что точно такие же, данные перемещаются с одного места в два или более различных процесса, элемента
хранения данных, или в источник/приемник (это обычно означает, что
разные копии одних и тех же данных перемещаются в разные места).
12. Объединение в потоке данных означает, что точно такие же данные
поступают от любого из двух или более различных процессов, элементов
хранения данных, или источников/приемников в общее место.
263
Окончание табл. 6.2
13. Поток данных не может перемещаться непосредственно обратно к тем
же процессам, из которых он выходит. На диаграмме должен быть, по
крайней мере, один процесс, который обрабатывает поток данных, производит некоторый другой поток данных и возвращает исходный поток данных начальному процессу.
14. Поток данных в элемент хранения данных означает обновление (добавление, удаление или изменение).
15. Поток данных из элемента хранения данных означает выборку/использование.
16. Поток данных имеет имя, представленное фразой из существительных.
На одной стрелке потока данных может появиться более чем одна фраза
из существительных, пока все потоки этой стрелки перемещаются вместе
в виде пакета.
То похожее, что может произойти на диаграмме, – это когда одинаковый поток входит и выходит из процесса, но процесс производит
также новый поток данных, являющийся результатом обработки
входного потока.
2. Объекты на DFD обладают уникальными именами. Каждый
процесс имеет уникальное имя. Не существует причины, чтобы два
процесса имели одно и то же имя. Тем не менее, чтобы DFD была
удобовоспринимаемой, имена элементов хранения, источников/приемников могут повторяться. Когда две стрелки имеют одно то
же имя потока данных, необходимо быть внимательным, чтобы эти
потоки на самом деле были тем же самым. Можно очень легко ошибиться и использовать одно и то же имя потока данных для пакетов
данных, являющихся почти тем же самым, но не являющихся идентичными. Имя потока данных представляет конкретный набор данных. Другому потоку данных, отличающемуся хотя бы на немного в
большую или меньшую сторону, должно быть предоставлено другое
уникальное имя.
Декомпозиция DFD. Предыдущий пример системы заказа пекарной продукции, был начат с контекстной диаграммы высокого уровня. Рассуждая далее о системе, можно было увидеть, что большая система состоит из четырех процессов. Закон перехода от одной систе264
мы до четырех составляющих процессов называется функциональной
декомпозицией. Функциональная декомпозиция является итерационным процессом декомпозиции описания системы на более мелкие и
мелкие подробности. Этот процесс создает набор иерархически связанных диаграмм, в котором один процесс на заданном графике объясняется более подробно на другой схеме. Для системы заказа пекарной продукции мы декомпозировали большую систему на четыре
процесса. Каждый полученный процесс (или подсистема) является
также кандидатом для декомпозиции. Каждый процесс может состоять из нескольких подпроцессов. Каждый подпроцесс также может
быть разбит на более мелкие единицы. Декомпозиция продолжается
до тех пор, пока не будет достигнута точка, в которой ни один подпроцесс логически не может быть разбит далее. Нижний уровень
DFD называется примитивной DFD, которая будет определена позднее в этом разделе.
Продолжая пример системы заказа пекарной продукции рассмотрим, как может быть дополнительно декомпозирован уровень 0 DFD.
Первый процесс на рис. 6.4, называется «Принять и преобразовать заказ», превращает заказ клиента (например, «Приобрести печенье песочное в количестве 100 единиц и рулет бисквитный в количестве 30
единиц штучного товара») в три различных выхода. Процесс 1 является хорошим кандидатом для декомпозиции. Рассуждая обо всех
различных задачах, которые должен выполнить процесс 1 можно выделить из них следующие: (1) принять заказ клиента, (2) преобразовать введенный заказ в форму производственного задания, (3) преобразовать заказ в печатную квитанцию для клиента и (4) превратить
заказ в данные об использованном сырье. По крайней мере, в процессе 1 могут возникнуть четыре логически отдельные функции. Декомпозиция процесса 1 в другую DFD может быть представлена, как показано на рис. 6.5.
Следует отметить, что каждый из четырех процессов в рис. 6.5 помечен как подпроцесс процесса 1: процессы 1.1, 1.2, 1.3 и 1.4. Также
необходимо обратить внимание, что, как и в других рассмотренных
265
DFD, каждый из процессов и потоков данных имеет имя. Заметим
также, что на DFD не представлено ни одного источника и приемника. Хотя источники и приемники могут быть и включены. DFD
рис. 6.5 называется схемой уровня 1. Если было бы необходимо аналогичным образом декомпозировать процессы 2, 3 и 4 DFD уровня 0,
то созданные DFD были бы также диаграммами уровня 1. В общем,
диаграмма уровня n – это DFD, которая генерируется из n вложенных
декомпозиций диаграммы уровня 0.
Рис. 6.5. Диаграмма уровня 1 процесса 1 уровня 0
системы заказа пекарной продукции
Процессы 2 и 3 уровня 0 функции похожи в том, что они оба используют входные данные для обновления элементов хранения данных. Поскольку обновление элементов хранения данных является
особой единичной логической функцией, ни один из этих процессов
особо не требует дальнейшей декомпозиции. Мы можем, однако, декомпозировать процесс 4 «Создать отчет для менеджера», по крайней
мере, на три подпроцесса: «Доступ к данным о запасах сырья и выпущенной продукции», «Агрегировать данные о выпущенной про266
дукции и использованном сырье» и «Подготовить управленческий
отчет». Декомпозиция процесса 4 показана на DFD уровня 1 рис. 6.6.
Рис. 6.6. Диаграмма уровня 1 процесса 4 уровня 0 системы
заказа пекарной продукции
Каждый уровень 1, 2, или n DFD представляет собой один процесс
DFD уровня n-1. Каждая DFD должны быть изображена на отдельной
странице. Как правило, ни одна DFD не должна иметь более чем около семи процессов, потому что слишком большое количество процессов делает диаграмму громоздкой и трудной для понимания. Чтобы
продолжить декомпозицию системы заказа пекарной продукции, мы
рассмотрим каждый из подпроцессов, выявленных в двух созданных
диаграммах уровня 1, в одной DFD для процесса 1 и в другой DFD
для процесса 4. В случае если мы решим, что какой-либо из этих подпроцессов должен быть дополнительно декомпозирован, мы создадим
диаграмму уровня 2, показывающую эту декомпозицию. Например,
если бы мы решили, что процесс 4.3 на рис. 6.6, должен быть дополнительно декомпозирован, мы бы создали диаграмму, которая бы выглядела, как это показано рис. 6.7. Опять же, необходимо обратить
внимание, как помечены подпроцессы.
Имена процессов должны отразить существенное действие процесса в нескольких словах, являющихся достаточными для описания дей267
ствия процесса так, чтобы каждый, прочитав имя, получил хорошее
представление о том, что делает процесс. Много раз, начинающие
изучать DFD пытались использовать в качестве имени процесса имена
людей, которые выполняют процесс, или отдела, в котором выполняется процесс. Эта практика не очень полезна, потому что мы больше
заинтересованы в действиях, представляемых процессом, чем в лицах,
осуществляющих его, или в месте, где это происходит.
Рис. 6.7. Диаграмма уровня 2 процесса 4.3 уровня 1
системы заказа пекарной продукции
Балансирование DFD. Когда декомпозируют DFD с одного уровня на другой, действует принцип сохранения. Необходимо сохранять
входы и выходы процесса при переходе на следующий уровень декомпозиции. Другими словами, процесс 1, который появляется в диаграмме уровня 0, должен иметь те же входы и выходы что и при его
декомпозиции на уровень 1 диаграммы. Это сохранение входов и выходов называют балансировкой.
Рассмотрим пример балансирования набора DFD. Обратимся к рис.
6.3. Здесь представлена контекстная диаграмма системы заказа пекарной продукции. Необходимо отметить, что на этой DFD существует
только два входа в систему, – заказ клиента, который берет свое начало
от клиента, и принятая на склад продукция – от склада. Отметим также,
что существует три выхода: квитанция клиента, производственное задание для цеха и управленческий отчет, предназначенный для менеджера. Теперь обратимся к рис. 6.4. Это схема уровня 0 для системы за268
каза пекарной продукции. Помним, что все элементы хранения данных
и потоки в или из них являются внутренними для системы. Обратим
внимание, что те же самые два входа в систему и три выхода, представленные в контекстной диаграмме, также появляются в диаграмме уровня 0. Как это очевидно, никакие новые входы или выходы из системы
не были добавлены. Таким образом, мы можем сказать, что контекстная
диаграмма и DFD уровня 0 сбалансированы.
Рассматривая диаграмму рис. 6.5, где был декомпозирован процесс 1 из DFD уровня 0, который, как было рассмотрено ранее, имеет один вход и три выхода (рис. 6.4), можно легко обнаружить тот
же единственный вход и три выхода. Здесь не было добавлено никаких новых входов или выходов. Сравнивая процесс 4 рис. 6.4 с его
декомпозицией на рис. 6.6, можно обнаружить туже сохранность
входов и выходов.
Рис. 6.8 показывает один пример того, как могла бы выглядеть несбалансированная DFD. Контекстная диаграмма показывает один
вход в систему – А, и один выход – Б. Тем не менее, в схеме уровня 0,
есть дополнительный вход В, и потоки А и В выходят из разных источников. Эти две DFD не сбалансированы. Если появляется вход на
уровне 0 диаграммы, он также должен появиться в контекстной схеме. Что случилось с этим примером? Может быть, при составлении
DFD уровня 0 аналитик понял, что системе также необходим поток
данных В для вычисления Б. Поток А и Б были оба изображены на
DFD уровня 0, но аналитик забыл обновить контекстную схему. При
выполнении корректировки, аналитик должен был бы также включить «Источник 1» и «Источник 2» в контекстную схему. Очень важно поддерживать диаграммы потока данных модели в сбалансированном состоянии, начиная с контекстной диаграммы, вдоль всего
пути, включающего каждый уровень создаваемых диаграмм.
Поток данных, состоящий из нескольких подпотоков на уровне n
диаграммы, может быть разделен на части на диаграмме уровня n + 1
для процесса, который принимает этот составной поток данных в качестве входных данных. Например, рассмотрим диаграмму рис. 6.9а.
269
На этом рисунке видно, что составной поток или пакет «Заказ и купон» является входом в процесс. То есть, «Заказ» и «Купон» всегда
перемещаются вместе и вводятся в процессе одновременно. На рис.
6.9б, процесс декомпозируется или разукрупняется на два подпроцесса, и каждый подпроцесс получает один из компонентов составного
потока данных от DFD верхнего уровня. Эти диаграммы также являются сбалансированными, потому что в каждую из диаграмм включены точно те же самые данные.
а)
б)
Рис. 6.8. Несбалансированный набор DFD
а) Контекстная диаграмма; б) Диаграмма уровня 0
Принцип сбалансированности и цель добиться, как можно более
простого представления DFD привели к четырем дополнительным
продвинутым правилам составления DFD. Эти правила приведены в
табл. 6.3. Правило 17 охватывает ситуацию, показанную на рис. 6.9.
Правило 18 охватывает принцип входов и выходов процесса. Правило 19 рассматривает одно исключение для балансировки. Правило 20
помогает, свести к минимуму запутанность на DFD.
270
а)
б)
Рис. 6.9. Пример разделения потоков данных
а) Составной поток данных; б) Разукрупненный поток данных
6.1.3. Использование DFD в процессе анализа
Изучение способа составления диаграмм потока данных является
важным, потому что они стали ключевым средством для проведения
процесса структурного анализа. Помимо вопроса составления механически правильных диаграмм потоков данных, есть и другие вопросы, связанные с моделированием процессов, которые должны беспокоить аналитиков. Такие вопросы, как являются ли диаграммы потока
данных полными и совместимыми на всех уровнях, или как можно
использовать DFD в качестве полезного инструмента для анализа,
рассматриваются в следующем разделе, который определяет руководящие принципы создания DFD.
271
Таблица 6.3
Дополнительные правила составления диаграмм потока данных
17. Смешанный поток данных на одном уровне может быть разделен на
подпотоки данных на следующем уровне. При этом не могут быть добавлены новые данные и все данные смешанного потока должны быть учтены в одном или нескольких подпотоков нижележащей диаграммы
18. Входы в процесс должны быть достаточными, чтобы обеспечить получение выходов из процесса (в том числе и данных, размещаемых в элементах хранения). Таким образом, из поступивших входных потоков могут создаваться все выходы. Все данные, поступившие ранее на вход,
пройдя через процесс, могут перемещаться куда угодно – к другому процессу или к элементу хранения данных, находящемуся за пределами данного процесса, или на более подробную DFD, показывающую декомпозицию этого процесса
19. На самом низком уровне DFD, могут быть добавлены новые потоки
данных для представления данных, которые передаются в исключительных условиях. Эти потоки данных, как правило, представляют собой сообщения об ошибках (например, «Клиент не известен», «Вы хотите создать нового клиента?») или уведомления для подтверждения (например,
«Вы хотите удалить эту запись?»).
20. Чтобы избежать пересечения линий потока данных друг с другом,
можно повторять элементы хранения данных или источники/приемники
на DFD. Для обозначения повторения используется дополнительный символ, такой как двойная линии на средней вертикальной линии символа
элемента хранения данных или диагональная линия в углу прямоугольника приемник/источник, чтобы указать повторение символа.
Принципы составления DFD. В этом разделе рассматриваются
дополнительные принципы для DFD, которые выходят за рамки простого механического рисования диаграмм и создают уверенность, что
правила, перечисленные в табл. 6.2 и 6.3, выполняются. Эти принципы включают в себя: полноту, совместимость, время, итеративную
природу составления DFD и примитивные диаграммы потоков
данных.
272
Полнота. Концепция полноты DFD связана с вопросом, включены
ли в DFD все компоненты, необходимые для моделируемой системы.
Если создаваемая DFD содержит потоки данных, которые не ведут
никуда или если ее элементы хранения данных, процессы или внешние объекты не связаны ни с чем, то создаваемая DFD не является
полной. Большинство CASE систем, автоматизирующих составление
DFD, имеет встроенные средства, которые можно выполнить для помощи в определении, является ли создаваемая DFD неполной. Когда
для системы разрабатывается много DFD, то возникновение ошибок
не является редкостью. Функции анализа CASE средств или сквозная
проверка модели совместно с другими аналитиками может помочь в
определении таких проблем.
Необходимо чтобы в DFD присутствовали не только все необходимые элементы, но и каждый из компонентов должен быть полностью описан в словаре (репозитории) проекта. В большинстве средств
CASE словарь проекта связан со схемой. То есть, когда определяется
процесс, поток данных, источник/приемник, или элемент хранения
для диаграммы потока данных, средство CASE автоматически создает запись в репозитории для этого элемента. Затем аналитик должен
войти в репозиторий и завершить полное описание элемента. Для
каждого из четырех типов элементов DFD требуется различная описательная информация. Каждое средство CASE или стандарт словаря
проекта, который приняла организации, имеет отличающуюся входную информацию для описания каждого из типов объектов DFD. Записи репозитория потока данных, как правило, включают в себя следующее.
x Метка или имя потока данных. Хранится так, как она ведена на
DFD. (Примечание: регистр и пунктуация особого значения здесь на
имеют, но если одна та же метка используется на нескольких DFD,
будь они вложенными или нет, то одна и та же запись репозитория
применяется к каждой ссылке этого имени.
x Краткое описание, определяющее поток данных.
273
x Список объектов репозитория, сгруппированных в категории по
типу объекта.
x Композиция или список элементов данных, содержащихся в потоке данных.
x Примечания, дополняющие ограниченную область описания потока и выходящие за рамки определения потока данных, применяемые для объяснения контекста и природы этого объекта репозитория.
x Список мест (имена DFD), в которых появляется этот поток
данных, и имена источников и направлений потока данных в каждой
из DFD.
Кстати, именно эта плотная связь между диаграммами и репозиторием CASE создает основную ценность средств CASE. Хотя и существуют очень сложные графические средства, также как и средства
для экранных форм и обработки текстов, но эти автономные системы
не интегрируют графические объекты с их структурными и текстовыми описаниями, как это делают средства CASE.
Согласованность. Понятие согласованности DFD определяет совместимость изображения системы, показанной на одном уровне вложенного множества DFD, с изображениями системы, показанными на
других уровнях. Грубым нарушением согласованности было бы изображение диаграммы 1-го уровня без диаграммы уровня 0. Другой
пример несогласованности бы поток данных, который присутствует
на более высоком уровне DFD, но не на более низких уровнях (это
называется нарушением балансировки). Еще одним примером несогласованности является поток данных, прикрепленный к одному объекту на диаграмме нижнего уровня, но также прикрепленный к другому объекту на более высоком уровне. Например, поток данных с
именем «Оплата», который служит в качестве входных данных для
процесса 1 на DFD уровня 0, появляется как вход процесса 2.1 на
диаграмме уровня 1 для процесса 2.
CASE средства также имеют инструменты анализа объектов, которые можно использовать для распознавания таких несоответствий
между вложенными DFD. Например, когда разработчик создает DFD,
274
используя CASE средство, большинство средств после получения команды декомпозировать процесс автоматически размещает входы и
выходы процесса на создаваемой DFD. При манипуляциях над созданной таким образом диаграммой нижнего уровня можно случайно
удалить или изменить поток данных, что может привести к нарушению баланса. В этом случае инструмент проверки согласованности
средства CASE является весьма полезным.
Время. Из некоторых примеров DFD можно заметить, что в них
упущен фактор времени. То есть, при рассмотрении DFD в ней не обнаруживается никаких признаков того, протекает ли поток данных
постоянно в реальном времени, или один раз в неделю, или раз в год.
Там также нет признаков того, когда будет работать система. Например, многие крупные системы обработки транзакций могут выполнять несколько крупных вычислительно-интенсивных работ в пакетном режиме в ночное время, когда нагрузка компьютерной системы
спадает. DFD не имеет возможности для указания такой ночной пакетной обработки. Когда создается DFD, то это делается так, как если
бы моделируемая система никогда не начинала работу и никогда не
останавливалась.
Итеративная разработка. Первая из составляемых начинающим
аналитиком DFD редко зафиксирует в совершенном виде моделируемую систему. Однако аналитик должен продолжать составлять эту
диаграмму снова и снова итеративным способом. С каждой новой попыткой он будет продвигаться ближе к хорошему приближению системы или аспекту моделируемой системы. Итерационная разработка
DFD считает, что определение требований и их структуризация являются итеративными, а не последовательными шагами фазы анализа
в жизненном цикле разработки систем.
Одно из правил гласит, что на составление одной диаграммы
должно требоваться как минимум три итерации. К счастью, средства
CASE существенно облегчают пересмотр создаваемой модели по
сравнению с тем, если бы при каждом таком пересмотре пришлось бы
использовать карандаш и шаблон.
275
Примитивные DFD. Одним из наиболее сложных решений, которое требуется сделать, когда составляются DFD, является определение момента, чтобы остановить декомпозицию процессов. Одно из
правил завершения составления состоит в достижении самого низкого логического уровня; Однако, это не всегда легко узнать, какой
уровень является самым низким логическим уровнем. Другие, более
конкретные правила, определяющие, когда нужно остановиться при
декомпозиции процессов, включают в себя следующие.
x Когда каждый процесс декомпозирован до единичных решений,
или единичного вычисления, или до одной операции над данными,
такой как выборка, добавление, обновление, создание или уничтожение.
x Когда каждый элемент хранения данных представляет данные
об одном объекте, таком как клиент, сотрудник, продукт или заказ.
x Когда пользователь системы не хочет видеть более подробные
детали или когда аналитики зафиксировали достаточно подробно детали для выполнения последующих задач разработки системы.
x Когда каждый поток данных не требует дальнейшего разделения, чтобы показать, что различные данные обрабатываются различными способами.
x Если аналитик верит, что показана каждая бизнес форма или
транзакция, компьютерная онлайновая экранная форма и отчет как
единичный поток данных (это часто означает, например, что каждая
экранная форма системы и название отчета соответствует имени отдельного потока данных).
x Когда появляется уверенность, что существует отдельный процесс для каждого выбора на всех опциях меню нижнего уровня системы.
Очевидно, что применение вышерассмотренных правил не гарантируют правильности прекращения процесса декомпозиции. Существование петель обратной связи в жизненном цикле разработки и
итеративность разработки предопределяют, что, несмотря на уверенность разработчика в выполнении правила остановки, позднее им мо276
гут быть обнаружены нюансы в системе, которые требуют дальнейшей декомпозиции набора DFD.
К тому времени, когда завершается декомпозиция DFD, она может
быть довольно подробной. По-видимому, простые действия, такие
как создание счета-фактуры, могут потребовать информацию из нескольких объектов, а также могут выдать разные результаты в зависимости от конкретной ситуации. Например, окончательная форма
счета-фактуры может находиться в зависимости от типа клиента (который будет определять процент скидки), от того где живет клиент
(что будет определять, например, налог с продаж), и от того как отправлен товар (от этого зависит стоимость доставки и обработки).
В DFD самого нижнего уровня, называемой примитивной DFD, все
эти условия должны быть предусмотрены. Учитывая количество рассмотренных подробностей для примитивной DFD, возможно, можно
понять, почему многие эксперты считают, что аналитики не должны
тратить свое время для полного описания текущей физической информационной системы, так как большая часть деталей будут отменена ими еще во время создания текущей логической DFD.
Использование принципов, изложенных в данном разделе, может
помочь в создании DFD, которые будут представлять собой нечто
большее, чем механически правильные диаграммы. Создаваемые DFD
будут также надежными и точными представлениями моделируемой
информационной системы. Примитивные DFD совместно с документацией, а также с результатами, полученными от других методов структурирования требований, должны быть проверены на совместимость и
после этого возможен переход к шагам проектирования системы.
Использование DFD как средства анализа. Мы видели, что DFD
являются многогранными средствами для моделирования процессов,
и что они могут быть использованы для моделирования систем физических или логических, текущих или замещающих. DFD также могут
быть использованы в процессе, называемом анализом пробелов или
просчетов. Аналитики могут использовать анализ пробелов, чтобы
обнаружить расхождения между двумя или более наборами DFD,
277
представляющими два или более состояния информационной системы, или несоответствия в пределах одной DFD.
После завершения создания DFD можно рассмотреть детали отдельных DFD для решения таких проблем, как избыточность потока
данных (данных, которые отражены, но которые не используются в
системе), а также данных, которые обновляются одинаково более чем
в одном месте. Эти проблемы могут не являться очевидными для
членов аналитической группы или других участников в процессе анализа, когда создавались DFD. Например, избыточные потоки данных
могли быть помечены различными именами при создании DFD. Теперь, когда группа аналитиков знает больше о моделируемой системе, такая избыточность может быть выявлена. Она может быть обнаружена наиболее легко из отчета репозитория средства CASE.
Например, многие средства CASE могут генерировать отчет, в котором перечислены все процессы, которые принимают конкретный
элемент данных в качестве входных данных (вспомним, список элементов данных является частью описания каждого потока данных).
На основе меток или имен этих процессов можно определить, отражены ли данные избыточно или поддерживаются ли одни и те же
данные более чем одним процессом. В таких выявленных случаях
DFD может вполне зеркально точно отражать фактическую реальность деятельности, происходящей в организации. Если на разработку бизнес-процессов, для которых были построены модели, затрачивается много времени и когда эта работа выполняется участниками
одной части организации, внедряющими процедуры, в изоляции от
других участников, то в результате в диаграммах, наверняка, может
получиться избыточность и пересечение ответственности. Внимательное изучение DFD, созданных на этапе анализа, может выявить
эту процедурную избыточность и дать возможность исправить ее.
Путем изучения DFD может также быть определена неэффективность. Существует большое разнообразие видов неэффективности,
которые могут существовать. Некоторые недостатки связаны с нарушениями правил составления DFD. Например, нарушение правила 18
278
из табл. 7.3 может произойти потому, что устаревшие данные фиксируются, но никогда не используется в системе. Другие виды неэффективность имеют место из-за чрезмерного количества шагов обработки. Рассмотрим, например, правильную DFD рис. 6.10. Хотя этот поток формально верен, но присутствующая в нем петля может указывать на потенциальные задержки в обработке данных или ненужные
операции утверждения.
Рис. 6.10. Петля, образуемая совокупностью потоков данных, в DFD
Подобным образом набор DFD, моделирующий текущую логическую систему, может быть сравнен с DFD, моделирующей новую логическую систему, чтобы лучше определить, какие процессы разработчики систем должны добавить или пересмотреть при построении
новой системы. Процессы, для которых входы, выходы и внутренние
шаги не были измены, возможно, могут быть повторно использованы
в строительстве новой системы. Можно также сравнить альтернативные логические DFD для определения тех нескольких элементов, которые должны быть обсуждены для оценки конкурирующих мнений
о системных требованиях. Логические DFD для новой системы также
могут служить основой для разработки альтернативных стратегий
проектирования новой физической системы.
279
6.2. Структурирование требований данных системы
В предыдущем разделе было рассмотрено моделирование и анализ
процессов, являющихся одним из важных компонентов информационной системы, при помощи потоков данных между ручной или автоматизированной обработкой. Однако этот метод не акцентировался
на данных, которые должны быть сохранены для поддержки описанного потока данных и обработки. Например, там было рассмотрено,
как показать в диаграмме потока данных элементы хранения данных
или данных в состоянии покоя. При этом, также, не была показана
естественная структура данных. DFD показывает, как, где и когда используются или изменяются данные в информационной системе, но
этот метод не показывают определение структур и отношений внутри
данных. Моделирование данных раскрывает эти недостающие и важные части описания системы.
В самом деле, некоторые разработчики систем считают, что модель
данных является наиболее важной частью формулировки требований
информационной системы. Эта уверенность основана на следующих
доводах. Во-первых, характеристики данных, полученные при моделировании данных, имеют решающее значение в разработке баз данных,
программ, компьютерных экранов и печатных отчетов. Например, такие факты, как: элемент данных является числовым, продукт может
быть записан только в одной строке продукта за один раз, строка заказа
клиента не может быть перемещена в другой заказ клиента, название
региона клиента ограничено заданным набором значений – все это составляет основные части информации, необходимой для обеспечения
целостности данных в информационной системе.
Во-вторых, данные, а не процессы, являются наиболее сложными
компонентами многих информационных систем и, следовательно,
претендуют на центральную роль в структурировании системных
требований. Системы обработки транзакций могут иметь высокую
сложность обработки при проверке данных, согласовании ошибок, а
также координации перемещения данных к различным базам данных.
Современная разработка систем больше фокусируется на информационных системах управления (например, таких как отслеживание про280
даж), системах поддержки принятия решений (например, краткосрочные денежные инвестиции), а также системах бизнес-аналитики
(например, анализ рыночной корзины). Такие системы являются более
информационно-интенсивными. В этом случае точная природа обработки является также более зависящей от случая, чем в системах обработки транзакций так, что детали этапов обработки не могут быть предвидены. Таким образом, цель разработки состоит в обеспечении богатого ресурса данных, который мог бы поддержать любой тип информационного запроса, анализа и обобщения.
В-третьих, характеристики данных (например, длина, формат и отношения с другими данными) являются достаточно постоянными и
имеют значительное сходство в различных организациях того же бизнеса. В отличие от этого, пути и дизайн потока данных являются достаточно динамичным. Модель данных объясняет характер присущий организации, а не ее переходные формы. Таким образом, дизайн информационной системы, основанный на ориентации на данные, а не на
процессы, должен иметь больший срок службы и общие черты для тех
же приложений или областей в различных организациях. Наконец, информация о структуре данных имеет важное значение для автоматической генерации программы. Например, тот факт, что заказ клиента имеет много позиций или строк, а не просто одну позицию влияет на автоматический дизайн экрана компьютерной формы для ввода заказов
клиентов. Хотя модель данных, документирует требования к файлам и
базе данных для информационной системы, бизнес-смысл или семантика данных, включенных в модель данных, имеет более широкое влияние на дизайн и конструкцию системы.
Наиболее распространенный формат для моделирования данных является составление диаграмм сущность-связь (E-R). Модели данных,
которые используют обозначения E-R диаграмм, объясняют характеристики и структуру данных независимо от того, как данные могут быть
сохранены в памяти компьютера. Модель данных, как правило, разрабатывается итеративно либо с нуля, либо из приобретенной модели
данных для поддержки отраслевой или подобной бизнес области. Планировщики информационных систем используют эту предварительную
281
модель данных для разработки модели данных масштаба предприятия с
очень широкими категориям данных и малыми подробностями. Далее,
на этапе определения проекта, строится конкретная модель данных,
чтобы помочь объяснить масштабы усилий конкретного системного
анализа и проектирования. Во время структурирования требований,
модель данных представляет концептуальные требования к данным для
конкретной системы. Затем, после того как подробно описаны входы и
выходы системы во время логического проектирования, модель данных
уточняется, прежде чем она трансформируется в логический формат
обычно реляционной модели данных, из которой создается определение и физическое дизайн базы данных. Модель данных представляет
определенные типы бизнес-правил, которые обуславливают свойства
данных. Бизнес-правила являются важными спецификациями бизнесполитики, что в идеале будет обеспечиваться через базу данных и систему управления базами данных, используемую, в конечном счете, для
приложения, которое разрабатывается. Большинство участников проекта должно знать оттенки, которые присущи процессу построения E-R
диаграмм на многих шагах разработки проекта системы, а также как
разрабатывать и читать диаграммы моделей данных. Таким образом,
овладение методами структурирования требований данных имеет решающее значение для успеха в команде проекта разработки систем.
6.2.1. Процесс логического моделирования данных
Моделирование данных может выполняться на нескольких фазах в
различных типах проектов разработки системы. Модели данных являются прогрессирующими: не существует такого понятия как
«окончательная» модель данных для бизнеса или приложения.
Наоборот, модель данных должна рассматриваться как документ, который будет изменяться, реагируя на изменение бизнеса. Модели
данных в идеале должны храниться в репозитории, чтобы они могли
быть восстановлены, расширены, и редактируемы в течение долгого
времени. Рассмотрим, как может выполняться моделирование данных
во время планирования и анализа системы.
282
Стратегическое моделирование данных. Многие организации выбирают проекты по разработке приложений, основываясь на стратегических планах информационных систем. Это случается наиболее часто
в организациях, в которых практикуется применение методологий, основанных на информационной инженерии. Стратегическое планирование является отдельным проектом. Этот проект производит стратегический план информационных систем, что определяет общую концепцию
и архитектуру информационных систем. Почти всегда, это архитектура
включает в себя модель данных предприятия.
Модель данных предприятия, как правило, определяет только самые основные из его объектов. Здесь сущности (объекты), как правило, только определяется (как в толковом словаре), но они не описываются в терминах ключей или атрибутов. Во многих моделях данных предприятия некоторые сущности могут состоять из нескольких
сущностей, которые не раскрывают, пока инициируются проект разработки приложения. Модель данных предприятия может включать
или не включать отношения (в зависимости от стандартов методологии планирования и уровня детализации, требуемой исполнительной
дирекцией). Если в модель включаются отношения, то многие из них
будут неспецифическими, т.е. отношениями «многие ко многим». Такие отношения подходят только для предварительных моделей и
должны быть уточнены насколько это возможно скорее.
Как модель данных предприятия влияет на последующую разработку системы? Часть плана информационной стратегии определяет проекты разработки приложений и устанавливает их приоритеты в соответствии с каким-либо критерием, которое сочтет необходимыми руководство. Когда эти проекты начинаются, соответствующие подмножества архитектуры информационных систем, в том числе подмножество
модели данных предприятия, передаются группе разработки информационной системы в качестве отправной точки дальнейшей разработки.
Моделирование данных и анализ систем. Модель данных предприятия, как правило, хранится в корпоративном репозитории. После
запуска проекта разработки приложения, подмножество модели данных предприятия (также как и других моделей) экспортируется из
283
корпоративного репозитория в репозиторий проекта. После того, как
группа проекта закончит анализ и проектирование системы, расширенные и усовершенствованные модели данных импортируются в
корпоративный репозиторий. В этом разделе рассматривается логическое моделирование данных, как часть анализа систем. Модель данных для одной системы или приложения обычно называют моделью
данных приложения. В строительных блоках информационных систем (рис. 4.1), логические модели данных фокусируются на «данных» и представлении «пользователи системы». Кроме того, как показано на рисунке, они, как правило, создаются как результаты выполнения фаз изучения и определения проекта. Наконец, необходимо
отметить, что в то время как логические модели данных не связаны с
деталями реализации или технологий, они могут быть построены (через обратный инжиниринг) из существующих баз данных.
Модели данных редко создаются на этапе обследования предприятия. Короткая продолжительность этой фазы делает их непрактичными. С другой стороны, если модель данных предприятия была создана на этой фазе, то подмножество этой модели, которое применимо к
проекту, может быть получено и рассмотрено как часть требований
фазы обследования для установления контекста. Кроме того, группа
проекта могла бы определить простой список объектов предприятия,
которые, как они считают, должна охватывать система в своих хранимых данных.
К сожалению, моделирование данных редко бывает связано с фазой обследования. Большинство аналитиков предпочитают рисовать
модели процессов, чтобы задокументировать существующую систему, но многие аналитики считают, что составление модели данных на
этой фазе значительно предпочтительнее по следующим причинам:
x Модели данных помогают аналитикам более полно определить
деловую лексику, чем модели процесса.
x Модели данных почти всегда строятся быстрее, чем модели процесса.
x Полная модель данных может поместиться на одном листе бумаги. Модели процессов часто требуют десятки листов бумаги.
284
x Моделировщики процессов слишком легко зацикливаются на ненужных деталях.
x Модели данных для существующих и предлагаемых систем гораздо больше похожи между собой, чем модели процесса для существующих и предлагаемых систем. Следовательно, применение моделей данных требует выполнения меньшего объема работ по мере движения
проекта к более поздним этапам.
Это действительно так. Модель фазы обследования включает в себя
только объекты, но никаких атрибутов – это контекстная модель данных. Здесь намерение разработчиков состоит в уточнении нашего понимание масштаба, не вдаваясь в подробности об объектах и бизнесправилах. При этом многие отношения могут быть созданы как неспецифические (что означает «многие-ко-многим»).
Модель данных может быть построена, по крайней мере, в два этапа:
1. Первоначально, составляется модель данных, основанная на ключах. Эта модель позволит устранить неспецифические отношения, добавить ассоциативные сущности, и включить в себя первичные, альтернативные ключи и внешние ключи. Модель, основанная на ключах,
также включает в себя точные значения мощности (кардинальности) и
любые иерархии обобщения.
2. Далее, составляется полностью определенная модель данных.
Эта модель включает в себя все остальные описательные атрибуты и
дискриптивные критерии подмножеств. Для каждого атрибута определяется тип данного, домен и значение по умолчанию, которые все
вместе запоминаются в репозитории. Это состояние модели иногда
называют полностью описанной моделью данных. Такая модель
определяет требования к данным разрабатываемой системы. Ее создание связано с затратами усилий группы специалистов, которая
включает в себя системных аналитиков, пользователей, менеджеров,
и аналитиков данных. Администратор данных часто устанавливает
стандарты для модели и утверждает все модели данных.
Завершенная модель данных представляет все бизнес-требования к
базе данных системы.
285
Обращаясь вперед к конфигурированию и проектированию системы. Логическая модель данных этапа анализа системы описывает
требования бизнес данных, а не технические решения. Целью последующей стадии конфигурирования и проектирования является определение наилучшего способа для реализации этих требований средствами технологий баз данных. На практике это решение может быть
стандартизировано в рамках архитектуры базы данных. Например,
компания SoundStage уже стандартизировала логическую модель данных на двух системах управления базами данных: Microsoft Access для
персональных баз данных и баз данных рабочих групп, а также
Microsoft SQL Server для корпоративных баз данных. Последняя будут
использоваться для Member Services Information System.
Во время проектирования системы, логическая модель данных преобразуется в физическую модель данных (в так называемую схему базы
данных) для выбранной системы управления базами данных. Эта модель
будет отражать технические возможности и ограничения этой технологии баз данных, также как и прилагаемые к ней требования настройки
производительности, предложенные администратором базы данных.
Физическая модель данных также будут проанализирована на адаптивность и гибкость посредством процесса, называемого нормализацией.
Выявление фактов и сбор информации при моделировании
данных. Модели данных не могут быть построены без соответствующих фактов и информации, предоставленной сообществом пользователей. Эти факты могут быть собраны несколькими способами, такими как отбор существующих форм и файлов, исследование подобных систем, опрос пользователей и менеджмента, а также интервьюирование пользователей и менеджмента. Быстрейшим способом сбора фактов и информации, и одновременно создания и проверки модели данных является Joint Application Development (JAD). JAD использует групповые совещания для сбора фактов, построения и проверки
модели, как правило, в один или двухдневный период сессии.
В табл. 6.4 приводятся вопросы, которые могли бы быть полезными для установления фактов и сбора информации для моделирования
данных.
286
Таблица 6.4
Вопросы для опроса при моделировании данных
Цель
Возможные вопросы
Выявить сущности Какие существуют сущности в данном бизнесе? Другими
системы
словами, какие типы лиц, организаций, подразделений,
мест, вещей, материалов или событий используются в или
взаимодействуют с системой, о которых должны фиксироваться или вестись данные? Сколько существует экземпляров каждой сущности?
Выявить ключи
Какая уникальная характеристика (или характеристики)
сущности
отличает экземпляр каждой сущности от других экземпляров той же сущности? Существуют ли какие-нибудь
планы изменить эту идентификационную схему в будущем?
Выявить критерии Есть ли какие-нибудь особенности у сущности, которые
разделения сущно- подразделяют все экземпляры этой сущности на полезные
сти на подмножеподмножества? Существуют ли какие-нибудь подмножества
ства у вышеуказанных сущностей, для которых не существует удобного способа группировки экземпляров?
Выявить атрибуты и Какие характеристики описывают каждую сущность? Для
домены
каждой из этих характеристик: (1) какой тип хранения у
этих данных? (2), кто отвечает за определение допустимых значений этих данных? (3) каковы допустимые значения этих данных? (4) требуется ли значение для данных
или данные могут быть не определены? и (5) есть ли значение по умолчанию, которое должно быть назначено,
если не указано иначе?
Выявить потребно- Есть ли ограничения на то, кто может видеть или испольсти безопасности и зовать определенные данные? Кому позволено создавать
контроля
эти данные? Кто имеет право обновлять эти данные? Кто
имеет право удалить эти данные?
Выявить потребно- Как часто меняются конкретные данные? В течение какости согласования
го периода времени эти данные представляют ценность
данных во времени для бизнеса? Как долго необходимо сохранять эти данные? Необходимы ли исторические данные или тренды?
Если какая-нибудь характеристика изменяется, необходимо ли знать новые значения?
287
Окончание табл. 6.4
Выявить иерархии
обобщения
Все ли экземпляры каждой сущности одинаковы? То есть,
существуют ли специальные типы каждой сущности, которые описываются или обрабатываются по-разному?
Могут ли какие либо из этих данные быть консолидированы для совместного использования?
Выявить отношения Какие происходят события, которые подразумевают ассои их степень
циации между сущностями? Какие бизнес-действия или
транзакции требуют обработки или изменения данных о нескольких различных сущностях того же или другого типа?
Выявить кардиОбрабатывается ли каждое бизнес-действие или событие
нальные числа
одинаковым образом, или есть ли там особые обстоятель(мощность)
ства? Может ли событие происходить только с некоторыми из ассоциированных сущностей, или должны быть вовлечены все сущности?
Автоматизированная инженерия систем (CASE) для моделирования данных. Модели данных хранятся в репозитории. В каком-то
смысле, модель данных это метаданные, то есть данные о бизнесданных. Автоматизированная инженерия систем (CASE) обеспечивает
ведение репозитория для хранения модели данных и ее подробного
описания. Большинство CASE продуктов поддерживают автоматизированное моделирование данных и проектирование баз данных. Некоторые CASE продукты (например, CA ERwin Data Modeler) поддерживают только моделирование данных и проектирования баз данных. CASE
берет на себя тяжелю работу создания изображений и поддержки этих
моделей, а также лежащих в их основе деталей.
Пользуясь CASE продуктом, можно легко создавать профессиональные, легко читаемые модели данных без бумаги, карандаша, ластика, и шаблонов.
Модели могут быть легко изменены для отражения исправлений и
изменений, предлагаемых конечными пользователями, без необходимости повторного выполнения всей работы с начала. Кроме того,
большинство продуктов CASE обеспечивают мощные аналитические
инструменты, которые могут проверить модели на механические ошибки, полноту и непротиворечивость. Некоторых CASE продукты могут
288
даже оказать помощь в анализе модели данных на непротиворечивость,
полноту и гибкость. При этом потенциальная экономия времени и качества являются существенными.
Средства CASE имеют свои ограничения. Не все преобразования
модели данных поддерживаются всеми продуктами CASE. Таким образом, очень вероятно, что любой данный CASE продукт может заставить компанию адаптировать обозначения своей методологии моделирования данных для того чтобы они работали в пределах ограничений CASE средства.
Все модели данных практического примера компании малого бизнеса
«Свежая выпечка», рассматриваемого в работе, были созданы при помощи CASE средства CA ERwin Data Modeler. Для изучения этого практического примера в настоящем разделе представляются распечатки моделей точно в таком виде, как если бы они пришли с принтера. В них отсутствует только цвет, а также внесены кое-где изменения оформительского
характера, которые концентрируют внимание на конкретные пункты,
представляющие интерес на этих распечатках. Все объекты, атрибуты и
отношения модели данных «Свежая выпечка» автоматически внесены в
каталог репозитория продукта CA ERwin Data Modeler. Рис. 6.11 иллюстрирует некоторые из экранов CA ERwin Data Modeler, которые показывают, как используется этот CASE продукт для моделирования данных.
6.2.2. Конструирование модели данных
Изучение вышерассмотренного материала позволяет узнать достаточно о моделях данных, чтобы их читать и интерпретировать. Однако, для системного аналитика или знающего пользователя этого недостаточно, потому что им необходимо уметь их строить. В этих целях
в этом разделе используется проект «Свежая выпечка», чтобы изучить, как составлять модели данных. Этот пример учит конструировать модели данных с нуля. В реальности нам всегда необходимо рассматривать существующие модели данных. Если такие модели существуют, они, как правило, поддерживается группой управления данными или группой администрирования данными.
289
Рис. 6.11. Средства CASE для моделирования данных
290
Выявление сущностей. Первая задача в моделировании данных
относительно легка. Необходимо выявить те основные сущности в
системе, которые описываются или могли бы быть описаны данными.
При этом мы не должны ограничиваться только сущностями, о которых конечные пользователи хотели бы хранить данные. Есть несколько методов, которые могут быть использованы для идентификации сущностей.
1. Во время интервью или сессиях JAD с владельцами и пользователями системы необходимо обращать внимание на ключевые слова
для их обсуждения. Например, во время интервью с человеком, обсуждая бизнес-среду и деятельность проекта «Свежая выпечка» пользователь может заявить: «Мы должны отслеживать и знать бригаду,
выпустившую данную партию данной продукции». Обратите внимание, что ключевыми словами в этом заявлении, являются БРИГАДА,
ПАРТИЯ и ПРОДУКТ. Эти все три слова являются сущностями.
2. Во время интервью или сессиях JAD необходимо конкретно
просить владельцев системы и пользователей определить объекты, о
которых они хотели бы собирать, хранить и вырабатывать информацию. Чаще всего, эти объекты представляют сущности, которые
должны быть изображены на модели данных.
3. Другой метод идентификации объектов является изучение существующих форм и файлов. Некоторые формы идентифицируют
сущности событий. Примеры включают ЗАКАЗ, ПРИЕМ ТОВАРА,
ПРЕТЕНЗИЯ, и так далее. Большинство из этих форм также содержат
данные, которые описывают другие объекты. Например, каждая из
упомянутых форм содержит данные о сущности ПРОДУКТ.
4. Технология также может помочь идентифицировать сущности.
Некоторые средства CASE способны трансформировать обратно существующие базы данных в физическую модель. Аналитик должен,
как правило, исправить полученную таким образом модель, заменив
физические имена, коды и комментарии их логическими бизнесдружественными эквивалентами.
291
Хотя эти методы могут оказаться полезными в идентификации
объектов, они время от времени подводят. Простая, быстрая проверка
качества может исключить ложные объекты. Попросите пользователя
указать количество экземпляров каждой сущности. Истинная сущность имеет множество экземпляров – десятки, сотни, тысячи, или
больше. Если нет, сущность является ложной.
После выявления сущностей, необходимо дать им простые, значимые бизнес-ориентированные имена. Сущности должны быть названы при помощи существительных, которые описывают человека, событие, место, объект или вещь, данные, которые мы хотим хранить.
Старайтесь не сокращать и не использовать аббревиатуры. Имена
должны быть в единственном числе, чтобы отличить логическое понятие сущности от реальных примеров (экземпляров) сущностей.
Имена могут включать в себя соответствующие прилагательные или
фразы для лучшего описания экземпляра сущности, например,
внешне генерированный ЗАКАЗ КЛИЕНТА должен отличаться от
внутренне созданного ЗАКАЗ ПОСТАВЩИКУ.
В то время как вышерассмотренные методы могут быть более
полезны на ранних стадиях, ближе к завершению моделирования
необходимо все же в максимальной степени использовать преимущества нисходящей методологии разработки. Это легко сделать путем поиска ответа на один вопрос может ли создаваемая модель
обеспечить данными и информацией функции, задачи, процессы,
цели и миссию, отраженные в стратегическом плане информационной системы, а также способствует ли она устранению имеющиеся
у предприятия проблемных областей и реализации критических
факторов успеха?
Каждая сущность определяется с точки зрения бизнеса. Не следует
определять ее при помощи технических терминов или как «данные
о...». Рекомендуется использовать толковый словарь, чтобы создать
словарь определений, а затем настроить его для бизнеса при помощи
близких по смыслу терминов, отражающих специфику прикладной
системы. Установленные имена сущностей и их определения должны
292
определить начальный глоссарий бизнес терминологии, который долгие годы будет служить аналитикам и пользователям.
Контекстная модель данных. Пример идентифицированных
сущностей для предприятия «Свежая выпечка» приведен в табл. 5.6.
Другие сущности могут быть выявлены позже в процессе дальнейшего развертывания модели данных. Следующая задача моделирования
данных состоит в построении контекстной модели данных. Контекстная модель данных включает в себя основные или независимые сущности, которые были выявлены.
Независимой сущностью является та сущность, которая существует независимо от наличия какого-либо другой сущности. Ее первичный ключ не содержит атрибуты, которые сделают его зависимой от
существования другой сущности. Независимые сущности являются
почти первыми сущностями, выявляемыми в результате опроса пользователей.
Отношения должны быть именоваться глагольной фразой, которая, в сочетании с именами сущностей, образующих простые бизнеспредложения или утверждения. Некоторые CASE средства, таких как
CA ERwin Data Modeler позволяет назвать отношения в обоих
направлениях. В противном случае, отношение всегда называют от
родителей к детям.
Пример контекстной модели данных для всего предприятия «Свежая выпечка» изображен на рис. 5.23. Для большего удобства изучения на рис. 6.12 представлена контекстная модель данных, представляющая небольшой фрагмент области того же предприятия. Этот
фрагмент может оказаться полезным для изучения, так как он представляет абстракции данных не только существующих физических
объектов, но также абстракции планирования продукции процесса
технологической подготовки производства и абстракции детального
пооперационного планирования расписания производственного процесса, направленного на выполнение заказов, поступивших от клиентов. Умение отображать такие данные является особенно важным в
современную эпоху становления и развертывания в промышленности
293
цифровых предприятий. Не следует отчаиваться, если такая модель не
получилась совершенной с первого раза, с первого раза совершенная
модель получается редко. После того как мы начинаем добавлять атрибуты, могут всплыть новые сущности и отношения.
Представленная на рисунке контекстная модель сообщает следующее.
СТРОКА ЗАКАЗА P
1
Подавать
2 Содержать
P
ЗАКАЗЧИК
Включаться
ЗАКАЗ
3
ПРОДУКТ/СЫРЬЕ
5
являться
являться
4
Z
11
Z
ПРОДУКТ
Планируется продукт
Планируется партия
ШАГ ТЕХНОЛОГИИ
СЫРЬЕ
8
6
Нормировать сырье
7
Z
Быть
15
Затребоваться
ИСПОЛЬЗУЕМОЕ СЫРЬЕ
9
Применяться
ТЕХНОЛОГИЧЕСКАЯ ОПЕРАЦИЯ
14
P
Используется
Закрепить
УЧАСТОК ПРОИЗВОДСТВА
13
12
ПАРТИЯ
10
P
СТРОКА РАСПИСАНИЯ
Планировать выпуск
Планировать потребность
ТРЕБУЕМОЕ СЫРЬЕ
Рис. 6.12. Контекстная модель данных «Свежая выпечка»
(1) ЗАКАЗЧИК не подает, или подает один или более ЗАКАЗ. Почему не подает? Заказчик недавно был зарегистрирован предприятием и еще не подал ни одного заказа. Один ЗАКАЗ подается всегда
только одним конкретным ЗАКАЗЧИК.
(2) ЗАКАЗ содержит в себе одну или более СТРОКА ЗАКАЗА. Заказ не может быть пустым. Каждая СТРОКА ЗАКАЗА содержится
294
только в одном конкретном ЗАКАЗ. Удовлетворение одной и той же
потребности в продукции не может осуществляться несколько раз.
(3) Каждый ПРОДУКТ/СЫРЬЕ может не включаться или включаться в одну или более СТРОКА ЗАКАЗА. Компания может предусмотреть хранение данных о продукте/сырье, которое еще не выпускается или не закупается. Это особенно справедливо, когда компания
готовится к выпуску новой продукции и использованию нового сырья. Почему ПРОДУКТ/СЫРЬЕ? Компания может реализовывать излишки или остатки сырья, особенно в случае приближения окончания
допустимого срока хранения, или в связи прекращением выпуска
определенной продукции. Одна СТРОКА ЗАКАЗА обязательно
включает один конкретный ПРОДУКТ/СЫРЬЕ. Строка не может
ссылаться на не существующую продукцию или сырье.
(4), (5) Один ПРОДУКТ/СЫРЬЕ может принадлежать либо к категории ПРОДУКТ, либо СЫРЬЕ. В реальности существует еще категория «полуфабрикат», которая в одних случаях может рассматриваться как продукт, а в других как сырье. В данном примере для
упрощения эта категория исключена из рассмотрения.
(6) ПРОДУКТ не планируется или планируется одним или более
ШАГ ТЕХНОЛОГИИ. Почему не планируется? Компания может
предусмотреть выпуск нового продукта на будущее, но еще не провести планирование технологии его изготовления. Каждая отдельная
строка ШАГ ТЕХНОЛОГИИ всегда планирует операции только для
одного ПРОДУКТ.
(7) ШАГ ТЕХНОЛОГИИ может не предусматривать или предусматривать нормирование одного или более видов ИСПОЛЬЗУЕМОЕ
СЫРЬЕ, например, мука, сахар, соль. Некоторые шаги технологического процесса могут не предусматривать использование сырья,
например, «выпечка». Нормирование подразумевает количество
определенного сырья на единицу измерения количества выпускаемого продукта. Каждая строка ИСПОЛЬЗУЕМОЕ СЫРЬЕ всегда нормируется только для одного ШАГ ТЕХНОЛОГИИ.
295
(8) Каждое СЫРЬЕ может не быть или быть один или более раз
ИСПОЛЬЗУЕМОЕ СЫРЬЕ. Сырье не является используемым, когда
оно предусмотрено для нового продукта, а планирование его еще не
произведено. ИСПОЛЬЗУЕМОЕ СЫРЬЕ всегда является одним из
предусмотренных видов СЫРЬЕ.
(9) ТЕХНОЛОГИЧЕСКАЯ ОПЕРАЦИЯ может не применяться или
применяться одним или более ШАГ ТЕХНОЛОГИИ. Технологическая операция не применяется, когда она предусмотрена для нового
продукта, но планирование продукта еще не проведено. Каждый
ШАГ ТЕХНОЛОГИИ всегда применяет только одну ТЕХНОЛОГИЧЕСКАЯ ОПЕРАЦИЯ.
(10) УЧАСТОК ПРОИЗВОДСТВА закрепляет за собой одну или
более ТЕХНОЛОГИЧЕСКАЯ ОПЕРАЦИЯ. ТЕХНОЛОГИЧЕСКАЯ
ОПЕРАЦИЯ всегда закрепляется только за одним УЧАСТОК ПРОИЗВОДСТВА.
(11) Каждый ПРОДУКТ может не планироваться или планироваться к выпуску в одной или более ПАРТИЯ. Выпуск продукта может не планироваться, когда он еще не запущен в производство, даже
если проведено его планирование. ПАРТИЯ всегда может планировать выпуск только одного ПРОДУКТ.
(12) Выпуск ПАРТИЯ планируется одной или более СТРОКА
РАСПИСАНИЯ. СТРОКА РАСПИСАНИЯ планирует всегда выпуск
только одной партии.
(13) СТРОКА РАСПИСАНИЯ может не планировать или планировать потребность в применении одного или более видов ТРЕБУЕМОЕ
СЫРЬЕ. Не во всех технологических операциях строк расписания применяется сырье. ТРЕБУЕМОЕ СЫРЬЕ в указанных количествах всегда
отражают потребность только одной СТРОКА РАСПИСАНИЯ.
(14) ТЕХНОЛОГИЧЕСКАЯ ОПЕРАЦИЯ может не использоваться
или использоваться в одной или более СТРОКА РАСПИСАНИЯ.
Операция может быть предусмотрена предприятием, но не использоваться в производственном процессе. СТРОКА РАСПИСАНИЯ всегда использует только одну технологическую операцию.
296
(15) СЫРЬЕ может не затребоваться или затребоваться один или
более раз в качестве ТРЕБУЕМОЕ СЫРЬЕ. Сырье не будет затребовано, если оно еще не используется предприятием в производстве
продукции, но данные о нем хранятся в системе. ТРЕУЕМОЕ СЫРЬЕ
всегда требует только один вид СЫРЬЕ.
Рассмотренные выше текстовые спецификации связей, дополненные подобными спецификациями сущностей и специфическими
ограничениями целостности, должны всегда сопровождать графическое представление модели данных. Все это совместно и представляет модель данных. Сейчас, наступило наиболее подходящий время, чтобы предупредить вполне ожидаемый вопрос читателя: «Какую цель преследует создание такой громоздкой и объемной конструкции словесных спецификаций»? Такие спецификации крайне
необходимы. Их следует создавать по двум причинам. Первая из них
связана с потребностью обеспечения однозначной семантической
интерпретации модели данных менеджерами и компьютером. Если
менеджмент, вникнув в суть текстовых определений, даст заключение, что они отражают бизнес-правила принятой стратегии ведения
бизнеса, то после дальнейшей автоматизированной доработки модели на следующих стадиях разработки до уровня выражений команд
SQL, используемая СУБД занесет их в свой системный словарь и
обеспечит их автоматическое выполнение. При этом, в свою очередь, попытки любой бизнес-транзакции занесения данных, нарушающих логику спецификаций модели, в базу данных будут автоматически отвергаться СУБД с выдачей соответствующего сообщения
в программу приложения, обрабатывающую эту транзакцию. В результате, «неправильная» бизнес-транзакция останется, в конечном
счете, невыполненной и соответственно данные этой транзакции не
будут записаны в базу данных. Таким образом, все вышеизложенное
совместно автоматически предотвратит возможные нарушения персоналом бизнес-правил принятой стратегии ведения деятельности
предприятия.
297
Модель данных, основанная на ключах. Следующая задача заключается в определении ключей каждой сущности. Для ее решения
предлагаются следующие рекомендации.
1. Значение ключа не должно меняться в течение жизни каждого
экземпляра сущности. Например, атрибут ФАМИЛИЯ был бы плохим ключом, поскольку фамилия человека может измениться в результате брака, развода или по другим причинам.
2. Значение ключа не может быть пустым.
3. Должен быть установлен контроль, гарантирующий допустимость значений, принимаемых ключами. Это может быть достигнуто
путем четкого определения понятия домена и с помощью элементов
управления проверкой значений ключей применительно к этому домену при вводе поступающих записей в базу данных СУБД.
4. Некоторые эксперты предлагают остерегаться интеллектуальных ключей. Интеллектуальный ключ – это бизнес код, структура
которого передает данные об экземпляре объекта (например, его
классификация, размер или другие свойства). Код представляет собой группу символов и/или цифр, которые идентифицируют и описывают что-то в бизнес-системе. Эксперты утверждают, что, поскольку эти характеристики могут меняться, то это нарушает вышерассмотренное правило номер 1. Например, как показала практика, нумерация групп студентов в университете при помощи составных кодов периодически подвергается изменениям по решению администрации.
На рис. 6.13 представлена модель данных, основанная на ключах,
для проекта «Свежая выпечка». Мы избежали всех неспецифических
отношений, превратив их в ассоциативные сущности и отношения
один-ко-многим (как описано ранее в этом разделе). Так как все отношения модели сейчас стали отношениями один-ко-многим, то
можно принять обычную практику именования отношения от родителя к ребенку. Обратное отношение, хотя это не показано, подразумевается. Обращается внимание на следующие примечательные
пункты.
298
2
4
1
4
1
1
1
6
1
5
2
4
6
7
3
7
1
4
1
4
2
4
1
3
7
7
Рис. 6.13. Модель данных, основанная на ключах
(1) Некоторые сущности имеют простой, одноключевой атрибут
первичного ключа (атрибуты, являющиеся первичными ключами?
обозначены на схеме особым символом слева от имени атрибута и
помещены в специально отведенное поле первичного ключа).
(2) Необходимо обратить внимание, как построены первичные
ключи для сущностей ЗАКАЗ и СТРОКА ЗАКАЗА. Последняя из них
имеет конкатенированный (составной, сцепленный) ключ. Часть этого ключа наследован от родительской сущности ЗАКАЗ. Можно сказать, что это из-за того, что атрибут НОМЕР ЗАКАЗА является внешним ключом (FK). Когда одна сущность вносит свой ключ в другую
сущность через связь (отношение), говорят, что это отношение является идентифицирующим, потому что он помогает определить дочер299
нюю сущность. Сама дочерняя сущность является зависимой по
идентификации от родительской сущности (потому, что родительская сущность передает ей свой первичный ключ).
(3) Неспецифическое отношение между СЫРЬЕ и ШАГ ТЕХНОЛОГИИ представляется путем введения ассоциативной сущности
ИСПОЛЬЗУЕМОЕ СЫРЬЕ. Каждый экземпляр ассоциативной сущности представляет собой один вид сырья на один шаг технологии.
Родительские сущности передают свои первичные ключи, чтобы содержать составной ключ ассоциативной сущности. Также необходимо обратить внимание, что каждый атрибут в этом составном ключе
является внешним ключом, который указывает обратно на соответствующий экземпляр родительский сущности.
(4) Все внешние ключи отношений передаются от родителя к ребенку. Как было только что определено выше, если переданный
внешний ключ помогает однозначно идентифицировать экземпляр
дочерней сущности, такое отношение называют идентифицирующим
отношением. С другой стороны, если внешний ключ не играет никакой роли в определении экземпляров дочерней сущности, то он будет
записан как не ключевые данные в нашей модели. Его единственной
целью является указать на конкретного родителя дочернего сущности. Например, КОД ПРОДУКТА в сущности СТРОКА ЗАКАЗА
служит только для указания правильного экземпляра сущности ЗАКАЗ. В этом случае, отношение называют неидентифицирующим.
Сама дочерняя сущность при этом является зависимой по существованию от родительской сущности, так как может ссылаться только на
существующий экземпляр родительской сущности.
Если невозможно определить ключи для сущности, может быть,
эта сущность на самом деле не существует, то есть, не существует
множества экземпляров этой, так называемой, сущности. Таким образом, установление ключей является хорошим контролем качества,
предшествующим определению всех атрибутов модели данных.
Обобщенные иерархии. Сейчас наступило подходящее время,
чтобы определить любые иерархии обобщения бизнес-задач. Проект
300
«Свежая выпечка в начале этой главы выявил, по крайней мере, одну
структуру супертип/подтип. В последующих обсуждениях были раскрыта иерархия обобщения, показанная на рис. 6.13. Применение в
данном случае иерархии обобщения позволяет несколько по иному и
более точно зафиксировать смысл содержания бизнес-проблемы в
модели данных. Ее включение в модель данных, не приводит к изменениям в отношениях и ключах, а только делает возможным конкретизировать подмножества участвующие в устанавливаемых отношениях. Обратим внимание на следующее.
(5) CA ERwin Data Modeler рисует специальный символ иерархии
обобщения.
(6) Подтипы наследуют ключи от супертипов.
(7) Применение иерархия обобщения отключает от непосредственной связи ПРОДУКТ/СЫРЬЕ от ШАГ ТЕХНОЛОГИИ и ПАРТИЯ с одной стороны и от ИСПОЛЬЗУЕМОЕ СЫРЬЕ и ТРЕБУЕМОЕ СЫРЬЕ с другой. Это сделано, чтобы точно и правильно
утверждать, что предприятие никогда не выпускает партии сырья и
не располагает технологией его изготовления, а также что однажды
выпущенный компанией продукт никогда и ни в каком виде не
участвует в последующей переработке и производстве, даже в целях сокращения расходов путем повторной переработки бракованной продукции.
Полностью определенная модель данных. Выявление оставшихся атрибутов данных может показаться тривиальной задачей; однако,
аналитики, не знакомые с моделированием данных, часто сталкиваются с проблемами. Чтобы выполнить эту задачу, необходимо иметь
глубокое понимание атрибутов данных системы. Эти факты могут
быть обнаружены с помощью нисходящих подходов (например, мозговой штурм) или восходящих подходов (таких как анализ образцов
форм и файлов). Если существует модель данных предприятия, некоторые (возможно, многие) из атрибутов, возможно, уже идентифицированы и зафиксированы в репозитории.
Предлагаются следующие рекомендации для выявления атрибутов.
301
x Многие организации имеют стандарты наименований и принятых сокращений. Администратор данных или репозитория, как правило, поддерживает такие стандарты.
x Выбирайте имена атрибутов тщательно. Многие атрибуты
имеют общие основания имени, такое как ИМЯ, АДРЕС, ДАТА. Если
атрибуты не могут быть обобщены в супертип, то лучше всего дать
каждой вариации уникальное имя, например,
ИМЯ ЗАКАЗЧИКА АДРЕС ЗАКАЗЧИКА
ДАТА ЗАКАЗА
ИМЯ ПОСТАВЩИКА АДРЕС ПОСТАВЩИКА ДАТА СЧЕТА
ИМЯ РАБОТНИКА АДРЕС РАБОТНИКА
ДАТА ПОЛЕТА
Кроме того, помните, что проект не живет в изоляции от других
проектов, в прошлом или будущем. Имена атрибутов разных проектов должны быть различимы.
Некоторые организации поддерживают многоразовые, глобальные
шаблоны для этих общих базовых атрибутов. Это способствует совместимости типов данных, доменов и значений по умолчанию для
всех приложений.
x Физические имена атрибутов существующих форм и отчетов,
часто сокращают для экономии места. Логические имена атрибутов
должны быть яснее, например, перевести атрибут COD формы заказа
в его логический эквивалент AMOUNT TO COLLECT ON DELIVERY. QTY перевести в QUANTITY ORDERED и так далее.
x Многие атрибуты принимают только значения «да» или «нет».
Попробуйте назвать эти атрибуты, как вопросы. Например, имя атрибута КАНДИДАТУРА НА СТЕПЕНЬ? предполагает значения «да» и
«нет».
Каждый атрибут должен быть отображен только на одну сущность. Если атрибут действительно описывает различные сущности,
это, вероятно, несколько различных атрибутов. Дайте каждому из них
уникальное имя.
x Внешние ключи являются исключением из правила неизбыточности атрибутов – они определяют ассоциированные экземпляры связанных сущностей.
302
x Домен атрибута не должен быть основан на логике. Например,
в случае «Свежая выпечка» мы узнали, что значения ПРОДУКТ/СЫРЬЕ зависят от его типа. Если тип СЫРЬЕ, то атрибутом
может быть КОЛИЧЕСТВО СЫРЬЯ НА СКЛАДЕ, которое измеряется в метрической системе веса с точностью до одной тысячной килограмма. Если тип ПРОДУКТ, то атрибутом может быть КОЛИЧЕСТВО ПРОДУКТА НА СКЛАДЕ, измеряемое в штуках.
Рис. 6.14 обеспечивает отображение атрибутов данных на сущности на этапе полного определения модели данных нашего проекта системы «Свежая выпечка».
Рис. 6.14. Полностью определенная модель данных
Полностью описанная модель. Последняя задача является наиболее трудоемкой. Она может быть запущена параллельно с моделью, основанной на ключах или полностью определенной моделью, но это, как
правило, последняя из выполняемых задач моделирования данных.
303
Полностью определенная модель данных определяет все атрибуты, которые выявляются и запоминаются в будущей базе данных. Но описания этих атрибутов являются неполными; они требуют доменов.
Большинство средств CASE предоставляют широкие возможности
для описания типов данных, доменов и значений по умолчанию для
всех атрибутов в репозитории. Кроме того, каждый атрибут должен
быть определен для использования в будущем.
В это время могут быть зафиксированы дополнительные описательные свойства для атрибутов. Например, кто должен создавать,
удалять, обновлять и получать доступ к каждому атрибуту? Как долго
каждый атрибут (или сущность), должны храниться до удаления или
архивирования данных? Администратор данных обычно решает какие из этих атрибутов являются достаточно важным для документирования.
Спрос на моделировании данных в качестве профессии зависит от
двух факторов: (1) необходимостью самих баз данных и (2) использованием технологии систем управления реляционными базами данных
для реализации этих баз данных. Что касается первого, базы данных
всегда будут востребованы в информационных системах. Будет ли
реляционная технология продолжать доминировать? Существует некоторые убеждения, что технология реляционных баз данных в конечном итоге будет заменена объектной технологией. Если бы это
произошло, моделирование данных должно было бы заменено технологией объектного моделирования. Считается, что это не произойдет
в ближайшее время. Спрос на новые технологии реляционных баз
данных продолжает расти, и этот спрос затмевает спрос на какуюлибо из технологий объектных баз данных, которые начинают появляться. По мере роста доступности технологии объектных баз данных
ожидается, что промышленность реляционных баз данных добавит
объектные функции и технологии к линейкам своих продуктов. Моделирование данных должно оставаться выгодным мастерством на
протяжении многих лет.
304
Ключевые термины
Анализ пробелов (разрывов)
Неспецифическое отношение
Ассоциативная сущность
Обобщение
Атрибут
Отношение
Балансировка
Первичный ключ
Внешний ключ
Подтип
Диаграмма потока данных (DFD) Полностью описанная модель
Диаграмма сущность-связь
данных
Диаграмма уровня 0
Полностью определенная модель
Диаграмма уровня n
данных
Замещающая система
Полнота DFD
Источник/приемник
Поток данных
Кардинальность
Примитивная DFD
Ключ
Процесс
Контекстная диаграмма
Согласованность DFD
Контекстная модель данных
Составной ключ
Логическая модель
Супертип
Метаданные
Сущность
Моделирование данных
Текущая система
Модель данных предприятия
Физическая модель
Модель данных, основанная наФункциональная декомпозиция
ключах
Экземпляр сущности
Независимая сущность
Элемент хранения данных
Неидентифицирующее отношение
Контрольные вопросы
1. Что такое DFD? Почему системный анализ использует DFD?
2. Объясните правила составления хороших DFD.
3. Что такое декомпозиция? Что такое балансировка? Как можно
определить, что DFD не отбалансирована?
4. Объясните правила для наименования различных уровней DFD.
5. Почему анализ предусматривает множественный набор DFD?
6. Как DFD может быть использована в качестве аналитического
средства?
305
7. Объясните принцип определения момента прекращения декомпозиции DFD?
8. Как вы определите, чем должен быть представлен компонент
системы процессом или источником/приемником?
9. Какие правила уникальности применяются при составлении
контекстных диаграмм?
10. Дать различие между логической и физической моделями.
Приведите три причины, почему логические модели являются предпочтительными для структурирования бизнес-требований.
11. Что такое сущность? Каковы пять категорий сущностей?
12. Различия между сущностями и экземплярами сущностей.
13. Что такое атрибуты? Приведите пример (не из главы).
14. Каковы три аспекта описания домена для атрибутов?
15. Что такое отношения? Почему отношения важно определить и
описать? Что такое неспецифические отношения?
16. Определите различие между кардинальностью и степенью.
17. Что такое ассоциативная сущность? Какую роль она играет в
тернарном отношении? Какую роль она играет в представлении неспецифических отношений?
18. Какую роль выполняет внешний ключ в реализации отношений?
19. Что такое обобщение, и каково его значение?
20. Определить различие между моделью данных предприятия и
моделью данных приложения.
21. Во время этапа обследования и анализа аналитик собирает
многочисленные образцы, включая документы, формы и отчеты.
Объясните, какую пользу они дают для моделирования данных?
22. Объясните задачи, решаемые при конструировании модели
данных приложения.
Глава 7. ПРОЕКТИРОВАНИЕ СИСТЕМ
Центром внимания этой главы является проектирование информационной системы, фаза, в которой проектировщик и пользователь
разрабатывают конкретное понимание того, как будет работать система. Действия в рамках проектирования не обязательно должны
быть последовательны. Например, проектирование данных, входов и
выходов системы и интерфейсов являются взаимодействующими
процессами, позволяющими определить недостатки и недостающие
элементы. Это означает, что репозиторий проекта или CASE репозиторий становится активным и развивающимся компонентом управления разработкой системы в ходе проектирования. Только тогда, когда
каждый элемент дизайна согласуется с другими, и каждый удовлетворяет конечного пользователя, тогда фаза проектирования является
завершенной.
Данные являются центральным элементом системы, дизайн и
структура данных изучаются во всех методологиях разработки системы. Мы видели, как используются диаграммы потока данных и диаграммы сущность-связь, чтобы описать требования к данным системы. Эти диаграммы являются гибкими и предоставляют значительную широту выбора для представления данных. Например, мы можем
использовать одну или несколько сущностей данных с процессом в
DFD. E-R диаграммы обеспечивают больше возможностей представления структуры, но сущность все еще может быть либо очень подробной или, более агрегированной. При проектировании базы данных, мы определяем данные в наиболее фундаментальной форме,
называемой нормализованной. Нормализация – это четко определенный метод идентификации отношений между каждым атрибутом
данных, представляющий все данные так, что они не могут быть логически разбиты на более подробные. Цель состоит в том, чтобы избавить проектные данных от нежелательных аномалий, порождаемых
избыточностью данных, которые могли бы сделать базу данных неэффективной и восприимчивой к ошибкам.
307
Раздел 7.2 посвящен принципам, которым необходимо следовать
при объединении всех входов и выходов системы вместе в общей
структуре взаимодействия между пользователями и системой. Системные интерфейсы и диалоги образуют «беседу», которая обеспечивает
доступ пользователей и навигацию между каждой функцией системы.
Раздел 7.2 специализируется на предоставлении спецификаций для
проектирования эффективных системных интерфейсов и диалогов, а
также на методах представления этих дизайнов, называемых схематическим изображением диалогов.
Результаты дизайна включают в себя подробные функциональные
спецификации для входов системы, выходов, интерфейсов, диалогов, и
базы данных. Часто эти элементы представляются в макетах или рабочих версиях. Репозиторий CASE обновляется для включения результата
проектирования каждой формы, отчета, интерфейса, диалога, и отношения. Из-за значительного участия пользователей в рассмотрении макетов и спецификаций при проектировании, и в связи с тем, что деятельность в рамках проектирования может быть запланирована со значительным перекрытием в базовом плане проекта, формальный обзор
после каждого вида работ иногда не производятся. Однако если макетирование не проводится, следовало бы проводить формальный обзор
после полного завершения стадии проектирования системы.
7.1. Проектирование базы данных
Проектирование любой базы данных, как правило, связано с администратором и персоналом базы данных. Они обрабатывают технические детали и комплексные вопросы приложений. Тем не менее, знание этого процесса полезно и для системного аналитика, чтобы понять основные принципы проектирования реляционных баз данных.
Правила проектирования, представленные здесь, на самом деле,
являются принципами. Мы не можем охватить каждую отдельную
отличительную особенность. Кроме того, поскольку в примере «Свежая выпечка» решено использовать технологию системы управления
308
базами данных IBM DB2 материал этого раздела будет ограничен
этой технологией. Каждая реляционная СУБД представляет свои собственные возможности и ограничения. Однако, руководящие принципы, представленные в разделе, являются довольно универсальными
и применимы к большинству сред СУБД. Курсы и учебники баз данных, которые должны быть предварительно освоены читателем, как
правило, охватывают более широкий спектр технологии и вопросов.
Автоматизированная инженерия систем (CASE) является на
протяжении уже более двадцати лет постоянной темой в сообществе
профессионалов по информационным системам и базам данных. Существуют конкретные продукты, предназначенные для анализа и
проектирования баз данных (например, CA ERwin Data Modeler).
Кроме того, большинство CASE-средств общего назначения в настоящее время также включают в себя средства проектирования баз данных. В нашем примере, продолжает использоваться CA ERwin Data
Modeler для проекта «Свежая выпечка». Наконец, большинство
средств CASE (в том числе CA ERwin Data Modeler) могут автоматически генерировать код SQL, чтобы построить структуры базы данных для наиболее популярных систем управления базами данных.
Эта возможность генерации кода дает огромную экономию времени.
Цели и предварительные условия к проектированию баз данных. Цели проектирования баз данных состоят в следующем.
x База данных должна обеспечить эффективное хранение, обновление и извлечение данных.
x База данных должна быть надежной – сохраненные данные
должны иметь высокую целостность, чтобы укреплять доверие пользователей к этим данным.
x База данных должна быть гибкой и масштабируемой для новых
и непредвиденных потребностей и приложений.
Модель данных системы – это в нашем случае, полностью определенная и нормализованная диаграмма сущность-связь (ERD) – используется в качестве отправной точки. Эта модель была ранее представлена, как показано, на рис. 6.14.
309
Модель данных, возможно, придется разделить на несколько моделей данных, чтобы отразить распределение и репликацию баз данных. Распределение данных имеет отношение к распределению либо
конкретных таблиц, записей, и/или полей по различным физическим
базам данных. Репликация данных относится к дублированию отдельных таблиц, записей и/или полей в нескольких физических базах
данных. Каждая подмодель или представление должно отражать данные, хранимые на одном сервере. Напомним, что распределенные и
реплицированные базы данных могут совместно использовать некоторые (или все) сущности или экземпляры сущностей. Система
«Свежая выпечка» может тиражироваться на любое количество пекарен малого предприятия; таким образом, в нашем случае достаточно
рассмотрения одной модели данных.
Схема базы данных. Результат проектирования базы данных
представляется как специальная модель, называемая схемой базы
данных. Схема базы данных – это физическая модель или чертеж базы данных. Он представляет техническую реализацию логической
модели данных.
Схема реляционной базы данных определяет структуру базы данных в терминах таблиц, ключей, индексов и правил целостности.
Схема базы данных определяет детали, исходя из возможностей, терминологии и ограничений выбранной системы управления базами
данных. Каждая СУБД поддерживает отличающиеся типы данных,
правил целостности, и так далее.
Преобразование логической модели данных в схему физической
реляционной базы данных регулируется некоторыми довольно общими правилами и возможностями. Эти правила, и руководящие
принципы заключаются в следующем.
1. Каждый основная, ассоциативная и слабая сущность реализуются в виде отдельной таблицы. Имена таблиц, возможно, придется отформатировать в соответствии с правилами именования и ограничениями размера, принятыми в используемой СУБД. Например, логический объект по имени КОЛИЧЕСТВО ПРОДУКТА НА СКЛАДЕ
310
может быть изменен на физическую таблицу с именем
КОЛ_ПРОД_НА_СКЛ. Соглашения об именовании также может регулироваться внутренними стандартами.
x Первичный ключ идентифицируется как таковой, и применяется
также в качестве индекса в таблице.
x Каждый вторичный ключ (альтернативный ключ, не использованный в качестве первичного ключа) реализуется в виде собственного индекса в таблице.
x Каждый внешний ключ должен быть реализован как таковой.
Включение этих внешних ключей реализует ER отношения в модели
реляционной базы данных и позволяет осуществлять соединение таблиц в SQL и прикладных программах.
x Атрибуты должны быть реализованы в виде полей. Эти поля соответствуют столбцам в таблице. Для каждого атрибута должны
устанавливаться, как правило, следующие технические детали. (Эти
данные могут быть автоматически сгенерированы средствами CASE
из логических описаний в модели данных).
i.
Имена полей – их, возможно, придется сократить и переформатировать в соответствии с ограничениями СУБД и внутренними правилами. Например, в логической модели данных, большинство
атрибутов может завершаться именем сущности (например, ИМЯ
ЗАКАЗЧИКА). В физической базе данных, мы могли бы просто использовать ИМЯ.
ii. Тип данных. Каждая СУБД поддерживает различные типы
данных и условия для этих типов данных. Например, различные системы могут назначить большое буквенно-цифровое поле по-разному
(например, MEMO в Access и LONG VARCHAR в Oracle). Кроме того, некоторые базы данных позволяют делать выбор между «без сжатия» и «со сжатием» неиспользуемого пространства (например,
CHAR и VARCHAR в Oracle).
iii. Размер поля. Различные СУБД выражают точность вещественных чисел по-разному. Например, в Oracle, спецификация поля
NUMBER (3,2) поддерживает диапазон от –9.99 до 9.99.
311
iv.
NULL или NOT NULL. Должно ли поле иметь значение,
прежде чем может быть совершена запись в хранилище? Опять же,
разные СУБД могут потребовать различные зарезервированные слова, чтобы выразить это свойство. Первичным ключам никогда не может быть разрешено иметь NULL значения.
v. Домены. Многие системы управления базами данных могут
автоматически изменять данные для того, чтобы поля содержали правильные данные. Это может быть весьма полезным для обеспечения
целостности данных независимо от прикладных программ. Если программист сделает ошибку, СУБД выявит ее. Но для тех СУБД, которые поддерживают целостность данных, должны быть четко указаны
правила на языке понятном СУБД.
vi. По умолчанию. Многие системы управления базами данных
позволяют использовать значение по умолчанию, которое автоматически будет присвоено полю в том случае, если пользователь или
программист представит запись без значения.
vii. Многие из указанных выше спецификаций были определены
как часть завершенной модели данных. Если эта модель данных была
разработана с помощью средства CASE, то CASE средство может
быть способно в дальнейшем автоматически транслировать модель
данных в язык выбранной технологии баз данных.
2. Сущности супертип/подтип представляют дополнительные возможности следующим образом.
x Большинство средств CASE не поддерживают в настоящее время конструкции, такие как супертипы и подтипы. Следовательно,
большинство CASE-средств исключают создание отдельных таблиц
для каждой сущности супертипа и подтипа.
x Кроме того, если подтипы имеют одинаковый размер и содержание данных, администратор базы данных может принять решение
свернуть подтипы в родительский и создать одну таблицу. Это создает определенные проблемы для установок по умолчанию и проверки
доменов. В профессиональных СУБД эти проблемы могут быть пре312
одолены путем встраивания значения по умолчанию и логику домена
в хранимые процедуры для таблицы.
3. Оценка и спецификация ограничений ссылочной целостности
(описано в следующем разделе).
Схема базы данных рассматриваемого примера «Свежая выпечка»,
автоматически сгенерированная из логической модели данных CASE
системой CA ERwin Data Modeler, показана на рис. 7.1.
Рис. 7.1. Начальная физическая схема базы данных «Свежая выпечка»
Хотели бы вы когда-нибудь подвергнуть риску сущности, находящиеся в третьей нормальной форме, при проектировании базы данных? Например, объединить две сущности находящиеся в третьей
нормальной форме, в одну таблицу (которая по умолчанию уже не
будет в третьей нормальной форме)? Обычно нет. Несмотря на это
313
администратор базы данных может пойти на такой риск, чтобы
улучшить производительность баз данных, но при этом он должен
тщательно взвесить преимущества и недостатки. Хотя такие преобразования могут означать большее удобство за счет уменьшения количества таблиц или лучшую общую производительность, такие комбинации также могут привести к возможной потере независимости – если добавленные в будущем новые поля приведут к необходимости
разделение такой таблицы обратно на две таблицы, программы должны быть переписаны. Как общее правило, комбинирование сущностей в таблицах не рекомендуется.
Данные и ссылочная целостность. Целостность базы данных
связана с доверием. Может бизнес и его пользователи доверять данным, хранимым в базе данных? Целостность данных обеспечивает
необходимые меры внутреннего контроля базы данных. Существует,
по крайней мере, три типа целостности данных, которые должны
быть спроектированы в любой базе данных.
Целостность ключей. Каждая таблица должна иметь первичный
ключ (который может быть составным). Первичный ключ должен
управляться таким образом, чтобы никакие две записи в таблице не
могли иметь одинаковые значения первичного ключа. (Заметим, что
для составного ключа, составное значение должно быть уникальным,
а не отдельные значения, из которых составляется ключ.)
Кроме того, первичному ключу, хранимому в записи, не должно
быть позволено иметь значение NULL. Это будет противоречить цели
первичного ключа однозначной идентификации записи. Если система
управления базами данных не соблюдает эти правила, должны быть
приняты другие меры для обеспечения их.
Целостность доменов. Должно быть разработано соответствующее управление, чтобы гарантировать, что ни одно поле таблиц не
принимает значение, выходящее за пределы диапазона допустимых
значений. Например, если СРЕДНИЙ БАЛЛ определяется как число
между 0,00 и 5,00, то управление должно быть реализовано так, чтобы предотвратить отрицательные числа и числа больше 5,00. Не так
314
давно прикладные программы были обязаны выполнять проверку и
редактирование данных при вводе их в систему. Сегодня большинство систем управления базами данных способны выполнять это редактирование данных. В обозримом будущем, ответственность за редактирование данных по-прежнему будет разделена между прикладными программами и СУБД.
Ссылочная целостность. Архитектура реляционных баз данных
реализует связи между записями в таблицах через внешние ключи.
Использование внешних ключей повышает гибкость и масштабируемость любой базы данных, но также увеличивает риск ссылочной
ошибки целостности.
Ошибка ссылочной целостности существует тогда, когда значение
внешнего ключа в одной таблице не соответствует ни одному значению первичного ключа связанной таблицы. Например, таблица ЗАКАЗ обычно включает в себя внешний ключ, КОД ЗАКАЗЧИКА,
чтобы «ссылаться обратно на» совпадающее значение первичного
ключа КОД ЗАКЗЧИКА в таблице ЗАКАЗЧИК. Что произойдет, если
удалить запись ЗАКАЗЧИК? Существует вероятность того, что мы
можем получить записи ЗАКАЗ, у которых КОД ЗАКАЗЧИКА не
имеет соответствующей записи в таблице ЗАКАЗЧИК. По сути, мы
пошли на нарушение ссылочной целостности между этими двумя
таблицами.
Как предотвращаются ошибки ссылочной целостности? При удалении записей из таблицы может случиться одно из двух. При рассмотрении удаления записей о ЗАКЗЧИК мы либо должны автоматически удалить все записи о ЗАКАЗ, которые имеют совпадающий
КОД ЗАКЗЧИКА (что бессмысленно с точки зрения бизнеса), либо
запретить удаление записи ЗАКАЗЧИК, до тех пор, пока мы не удалим все соответствующие записи ЗАКАЗ.
Ссылочная целостность определяется в виде правил удаления следующим образом.
x Нет ограничений. Любая запись в таблице, может быть удалена
без учета каких-либо записей в любых других таблицах.
315
Глядя на окончательную модель данных «Свежая выпечка» мы
не могли бы применить это правило ни к одной из ее таблиц.
x Удалить каскадно. Удаление записи в таблице должно автоматически привести к удалению совпадающих записей в связанной таблице. Многие реляционные СУБД могут автоматически применять
правила delete:cascade, используя триггеры.
В модели данных «Свежая выпечка», примером правильного
правила delete:cascade могло бы быть удаление от ЗАКАЗ к СТРОКА
ЗАКАЗА. Другими словами, если мы удаляем определенный ЗАКАЗ,
мы должны автоматически удалить все соответствующие СТРОКА
ЗАКАЗА для этого заказа.
x Удалить ограниченно. Удаление записи в таблице должны быть
запрещено, пока все совпадающие записи не будут удалены из связанной таблицы. Опять же, многие реляционные СУБД могут автоматически применять правила delete:restrict.
Например, в модели данных «Свежая выпечка», мы могли бы указать,
что мы должны запретить удаление какого-либо ЗАКАЗа, пока существует СТРОКА ЗАКАЗА с заказанным товаром для данного заказа.
x Удалить с установкой неопределенного значения. Удаление записи в таблице должно автоматически сопровождаться заменой совпадающих значений ключей в связанной таблице на неопределенное
значение NULL. Опять же, многие реляционные СУБД могут применять такое правило через триггеры.
Опция Delete:Set null не была использована в модели данных
«Свежая выпечка». Она используется только тогда, когда мы готовы
удалить запись родительской таблицы, но не хотим, удалить соответствующие записи таблицы транзакций по историческим причинам.
При установке внешнего ключа в NULL мы подтверждаем, что запись
не указывает обратно к соответствующей родительской записи, и при
этом мы, по крайней мере, не имеем ее, указывая на несуществующую родительскую запись.
Окончательная схема базы данных, дополненная правилами ссылочной целостности, показана на рис. 7.2. Она является рабочим чер316
тежом для написания SQL кода (или его эквивалента) для создания
таблиц и структур данных.
Рис. 7.2. Окончательная физическая схема
базы данных «Свежая выпечка»
Роли. Некоторые разработчики баз данных утверждают, что никакие два поля не должны иметь одинаковое имя. Это ограничение
упрощает документацию, справочные системы, а также определения
метаданных. Такая рекомендация представляет очевидную проблему
с внешними ключами. По определению, внешний ключ должен иметь
соответствующий первичный ключ. Во время логического моделирования данных, использование одного и того же имени подходило для
нашей цели оказания пользователям помощи в понимании, что эти
внешние ключи позволяют нам ставить в соответствие связанные за317
писи в различных сущностях. Но в физической базе данных, это не
всегда необходимо или даже желательно иметь эти избыточные имена полей в базе данных.
Чтобы решить эту проблему внешним ключам могут быть даны
имена ролей.
Имя роли – это альтернативное имя внешнего ключа, которое четко определяет цель, которую выполняет внешний ключ в таблице.
Например, в схеме базы данных «Свежая выпечка», КОД ПРОДУКТА/СЫРЬЯ является первичным ключом для таблицы ПРОДУКТ/СЫРЬЕ и внешним ключом в таблицах ПРОДУКТ и СЫРЬЕ.
Имя первичного ключа не должно быть изменено в таблице ПРОДУКТ/СЫРЬЕ. Но возможно имеет смысл переименование внешних
ключей на КОД ПРОДУКТА и КОД СЫРЬЯ для более точного отражения их роли в таблицах ПРОДУКТ и СЫРЬЕ.
Решение использования или не использования имен ролей, как
правило, принимается администратором данных или базы данных.
Макеты базы данных. Макетирование (прототипирование) не является альтернативой тщательно продуманной схеме базы данных. С
другой стороны, если схема завершена, макет базы данных, как правило, может быть сгенерирован очень быстро. Большинство современных СУБД включают в себя мощные, управляемые с помощью
меню, генераторы базы данных, которые автоматически создают DDL
(текст определения данных на подмножестве Data Definition Language
SQL) и генерируют макет базы данных в соответствии с полученной
последовательностью команд DDL. Затем база данных может быть
загружена тестовыми данными, которые окажутся полезными для макетирования и тестирования выходов, входов, экранных форм и других компонентов системы.
Планирование емкости базы данных. База данных хранится на
диске. В конечном счете, администратор базы данных должен будет
дать оценку дискового пространства, для новой базы данных, чтобы
гарантировать наличие достаточного дискового пространства для
доступа. Планирование емкости базы данных может быть рассчита318
но при помощи простой арифметики следующим образом. Эта простая формула игнорирует такие факторы, как упаковка, кодирование
и сжатие, но оставляя в стороне эти возможности, мы добавляем резерв емкости.
1. Для каждой таблицы, необходимо суммировать размеры полей.
В результате будет получен размер записи таблицы. Избегайте принимать в расчет результат сжатия, кодирования и упаковки, другими
словами, предположим, что каждый сохраненный знак и цифра будет
занимать один байт памяти. Необходимо отметить, что символы
форматирования (например, запятые, дефисы, косая черта, и т.д.), почти никогда не хранятся в базе данных. Эти символы форматирования добавляются прикладными программами, которые будут иметь
доступ к базе данных и представлять выход для пользователей.
2. Для каждой таблицы, необходимо умножить размер записи на
количество экземпляров сущностей, которые будут включены в таблицу. Рекомендуется рассматривать базы данных на разумный период
времени (например, три года). В результате получится размер таблицы. Затем необходимо просуммировать размеры всех таблиц. Это будет размер базы данных.
3. Дополнительно можно добавить резервную емкость буфера
(например, 10 процентов) с учетом непредвиденных факторов или неточности вышерассмотренной оценки. Это и будет ожидаемая емкость базы данных.
Генерация структуры базы данных. Средства CASE зачастую
способны генерировать код SQL для базы данных непосредственно из
схемы базы данных, основанной на CASE. Этот код можно экспортировать в СУБД для компиляции. Даже небольшая база данных, такие
как модель «Свежая выпечка» может потребовать 50 страниц и более
кода на языке определения данных SQL для создания таблиц, индексов, ключей, полей и триггеров. Очевидно, что способность CASE для
автоматической генерации синтаксически правильного кода является
огромное преимуществом производительности. Кроме того, почти всегда оказывается проще изменить схему базы данных и восстановить
код, чем непосредственно поддерживать код. Рис. 7.3 представляет
319
фрагмент кода, генерируемого CA ERwin Data Modeler на основе схемы базы данных. «Свежая выпечка».
CREATE TABLE ЗАКАЗЧИК
(
Код_заказчика DECIMAL(7) NOT NULL ,
Имя_заказчика CHAR(18),
Адрес CHAR(30));
ALTER TABLE ЗАКАЗЧИК
ADD CONSTRAINT XPKЗАКАЗЧИК PRIMARY KEY (Код_заказчика);
CREATE TABLE ЗАКАЗ
(
Номер_заказа INTEGER NOT NULL ,
Дата TIMESTAMP,
Код_заказчика DECIMAL(7) NOT NULL );
ALTER TABLE ЗАКАЗ
ADD CONSTRAINT XPKЗАКАЗ PRIMARY KEY (Номер_заказа);
CREATE TABLE СТРОКА_ЗАКАЗА
(
Номер_заказа INTEGER NOT NULL ,
Код_продукта_сырья DECIMAL(6) NOT NULL ,
Количество DECIMAL(7,2),
Номер_строки DECIMAL(3) NOT NULL);
ALTER TABLE СТРОКА_ЗАКАЗА
ADD CONSTRAINT XPKСТРОКА_ЗАКАЗА PRIMARY KEY (Номер_заказа,Номер_строки);
ALTER TABLE ЗАКАЗ
ADD CONSTRAINT R_6 FOREIGN KEY (Код_заказчика) REFERENCES
ЗАКАЗЧИК (Код_заказчика)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE СТРОКА_ЗАКАЗА
ADD CONSTRAINT R_1 FOREIGN KEY (Номер_заказа) REFERENCES
ЗАКАЗ (Номер_заказа)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
CREATE TRIGGER tD_ЗАКАЗЧИК AFTER DELETE ON ЗАКАЗЧИК
REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL
WHEN ((SELECT count(*) FROM ЗАКАЗ WHERE ЗАКАЗ.Код_заказчика =
old.Код_заказчика) > 0)
/* ERwin Builtin Trigger */
/* ЗАКАЗЧИК Подавать ЗАКАЗ on parent delete no action */
/* ERWIN_RELATION:CHECKSUM=«00008424», PARENT_OWNER=««, PARENT_TABLE=«ЗАКАЗЧИК»
CHILD_OWNER=««, CHILD_TABLE=«ЗАКАЗ»
P2C_VERB_PHRASE=«Подавать», C2P_VERB_PHRASE=««,
FK_CONSTRAINT=«R_6», FK_COLUMNS=«Код_заказчика» */
SIGNAL SQLSTATE '75001' ('Cannot delete ЗАКАЗЧИК because ЗАКАЗ exists.')
Рис. 7.3. SQL код для создания части базы данных «Свежая выпечка»
320
7.2. ɉɪɨɟɤɬɢɪɨɜɚɧɢɟ ɢɧɬɟɪɮɟɣɫɨɜ ɢ ɞɢɚɥɨɝɨɜ
ɗɬɨɬ ɪɚɡɞɟɥ ɪɚɫɫɦɚɬɪɢɜɚɟɬ ɷɬɚɩ ɩɪɨɟɤɬɢɪɨɜɚɧɢɹ ɢɧɬɟɪɮɟɣɫɨɜ ɢ
ɞɢɚɥɨɝɚ ɫɢɫɬɟɦɵ. Ɍɚ ɱɚɫɬɶ ɩɪɨɟɤɬɢɪɨɜɚɧɢɹ, ɤɨɬɨɪɚɹ ɢɦɟɟɬ ɞɟɥɨ ɢɧɬɟɪɮɟɣɫɨɦ, ɤɨɧɰɟɧɬɪɢɪɭɟɬɫɹ ɧɚ ɬɨɦ, ɤɚɤ ɩɪɟɞɫɬɚɜɥɹɟɬɫɹ ɩɨɥɶɡɨɜɚɬɟɥɹɦɢ ɢ ɤɚɤ ɜɨɫɩɪɢɧɢɦɚɟɬɫɹ ɨɬ ɧɢɯ ɢɧɮɨɪɦɚɰɢɹ. Ⱦɪɭɝɚɹ ɱɚɫɬɶ – ɩɪɨɟɤɬɢɪɨɜɚɧɢɟ ɞɢɚɥɨɝɨɜ, ɫɨɫɪɟɞɨɬɚɱɢɜɚɟɬɫɹ ɧɚ ɩɨɫɥɟɞɨɜɚɬɟɥɶɧɨɫɬɢ
ɷɤɪɚɧɧɵɯ ɮɨɪɦ ɢɧɬɟɪɮɟɣɫɚ.
Ⱦɢɚɥɨɝɢ ɚɧɚɥɨɝɢɱɧɵ ɪɚɡɝɨɜɨɪɭ ɦɟɠɞɭ ɞɜɭɦɹ ɥɸɞɶɦɢ. Ƚɪɚɦɦɚɬɢɱɟɫɤɢɟ ɩɪɚɜɢɥɚ, ɤɨɬɨɪɵɦ ɩɪɢɞɟɪɠɢɜɚɟɬɫɹ ɤɚɠɞɵɣ ɱɟɥɨɜɟɤ ɜɨ ɜɪɟɦɹ
ɪɚɡɝɨɜɨɪɚ, ɹɜɥɹɸɬɫɹ ɚɧɚɥɨɝɚɦɢ ɢɧɬɟɪɮɟɣɫɚ. Ɍɚɤɢɦ ɨɛɪɚɡɨɦ, ɞɢɡɚɣɧ
ɢɧɬɟɪɮɟɣɫɨɜ ɢ ɞɢɚɥɨɝɨɜ ɹɜɥɹɟɬɫɹ ɩɪɨɰɟɫɫɨɦ ɨɩɪɟɞɟɥɟɧɢɹ ɫɩɨɫɨɛɚ,
ɩɪɢ ɩɨɦɨɳɢ ɤɨɬɨɪɨɝɨ ɥɸɞɢ ɢ ɤɨɦɩɶɸɬɟɪɵ ɨɛɦɟɧɢɜɚɬɶɫɹ ɢɧɮɨɪɦɚɰɢɟɣ. ɏɨɪɨɲɢɣ ɱɟɥɨɜɟɤɨ-ɤɨɦɩɶɸɬɟɪɧɵɣ ɢɧɬɟɪɮɟɣɫ ɨɛɟɫɩɟɱɢɜɚɟɬ ɭɧɢɮɢɰɢɪɨɜɚɧɧɭɸ ɫɬɪɭɤɬɭɪɭ ɞɥɹ ɩɨɢɫɤɚ, ɩɪɨɫɦɨɬɪɚ ɢ ɜɵɡɨɜɚ ɪɚɡɥɢɱɧɵɯ
ɤɨɦɩɨɧɟɧɬɨɜ ɫɢɫɬɟɦɵ. Ɂɞɟɫɶ ɪɚɫɫɦɚɬɪɢɜɚɟɬɫɹ ɧɚɜɢɝɚɰɢɹ ɦɟɠɞɭ ɮɨɪɦɚɦɢ, ɚɥɶɬɟɪɧɚɬɢɜɧɵɟ ɫɩɨɫɨɛɵ ɜɵɡɨɜɚ ɩɨɥɶɡɨɜɚɬɟɥɹɦɢ ɮɨɪɦ ɢ ɨɬɱɟɬɨɜ, ɚ ɬɚɤɠɟ ɞɨɩɨɥɧɟɧɢɟ ɫɨɞɟɪɠɚɧɢɹ ɮɨɪɦ ɢ ɨɬɱɟɬɨɜ ɫɪɟɞɫɬɜɚɦɢ ɩɨɦɨɳɢ ɩɨɥɶɡɨɜɚɬɟɥɹɦ ɢ ɫɨɨɛɳɟɧɢɹ ɨɛ ɨɲɢɛɤɚɯ.
7.2.1. ɉɪɨɟɤɬɢɪɨɜɚɧɢɟ ɢɧɬɟɪɮɟɣɫɨɜ
ɇɟ ɜɞɚɜɚɹɫɶ ɜ ɜɨɩɪɨɫɵ ɩɪɨɟɤɬɢɪɨɜɚɧɢɹ ɫɨɞɟɪɠɚɧɢɹ ɮɨɪɦ ɢ ɨɬɱɟɬɨɜ,
ɪɚɡɞɟɥ ɪɚɫɫɦɚɬɪɢɜɚɟɬ ɩɪɨɟɤɬɢɪɨɜɚɧɢɟ ɦɚɤɟɬɨɜ ɢɧɬɟɪɮɟɣɫɚ. Ɉɧ ɫɨɞɟɪɠɢɬ
ɪɟɤɨɦɟɧɞɚɰɢɢ ɩɨ ɫɬɪɭɤɬɭɪɢɪɨɜɚɧɢɸ ɢ ɭɩɪɚɜɥɟɧɢɸ ɩɨɥɹɦɢ ɜɜɨɞɚ ɞɚɧɧɵɯ, ɨɛɟɫɩɟɱɟɧɢɸ ɨɛɪɚɬɧɨɣ ɫɜɹɡɢ, ɚ ɬɚɤɠɟ ɢɧɬɟɪɚɤɬɢɜɧɨɣ ɫɩɪɚɜɤɢ. ɗɮɮɟɤɬɢɜɧɨɟ ɩɪɨɟɤɬɢɪɨɜɚɧɢɟ ɢɧɬɟɪɮɟɣɫɚ ɬɪɟɛɭɟɬ, ɱɬɨɛɵ ɪɚɡɪɚɛɨɬɱɢɤ ɢɦɟɥ
ɩɨɥɧɨɟ ɩɪɟɞɫɬɚɜɥɟɧɢɟ ɨ ɤɚɠɞɨɣ ɢɡ ɷɬɢɯ ɤɨɧɰɟɩɰɢɣ.
ɉɪɨɟɤɬɢɪɨɜɚɧɢɟ ɦɚɤɟɬɨɜ. ɑɬɨɛɵ ɨɛɥɟɝɱɢɬɶ ɨɛɭɱɟɧɢɟ ɩɨɥɶɡɨɜɚɬɟɥɟɣ ɢ ɡɚɧɟɫɟɧɢɟ ɢɦɢ ɞɚɧɧɵɯ, ɧɟɨɛɯɨɞɢɦɨ ɢɫɩɨɥɶɡɨɜɚɬɶ ɫɬɚɧɞɚɪɬɧɵɟ ɮɨɪɦɚɬɵ ɞɥɹ ɷɤɪɚɧɧɵɯ ɮɨɪɦ ɢ ɨɬɱɟɬɨɜ, ɩɨɞɨɛɧɵɯ ɬɟɦ, ɤɨɬɨɪɵɟ
ɢɫɩɨɥɶɡɭɸɬɫɹ ɞɥɹ ɛɭɦɚɠɧɵɯ ɮɨɪɦ ɢ ɨɬɱɟɬɨɜ ɞɥɹ ɡɚɩɢɫɢ ɢɥɢ ɩɪɟɞɫɬɚɜɥɟɧɢɹ ɢɧɮɨɪɦɚɰɢɢ.
321
Ɍɢɩɢɱɧɚɹ ɛɭɦɚɠɧɚɹ ɮɨɪɦɚ ɫɱɟɬɚ-ɮɚɤɬɭɪɵ ɞɥɹ ɩɪɨɞɚɠ ɩɨɤɚɡɚɧɚ ɧɚ
ɪɢɫ. 7.4. ɗɬɚ ɮɨɪɦɚ ɢɦɟɟɬ ɧɟɫɤɨɥɶɤɨ ɨɛɳɟɩɪɢɧɹɬɵɯ ɨɛɥɚɫɬɟɣ, ɨɛɳɢɯ
ɞɥɹ ɛɨɥɶɲɢɧɫɬɜɚ ɮɨɪɦ:
x ɢɧɮɨɪɦɚɰɢɹ ɡɚɝɨɥɨɜɤɚ;
x ɢɧɮɨɪɦɚɰɢɹ ɨ ɩɨɫɥɟɞɨɜɚɬɟɥɶɧɨɫɬɢ ɢ ɜɪɟɦɟɧɢ;
x ɢɧɫɬɪɭɤɰɢɹ ɢɥɢ ɢɧɮɨɪɦɚɰɢɹ ɩɨ ɮɨɪɦɚɬɢɪɨɜɚɧɢɸ;
x ɬɟɥɨ ɢɥɢ ɩɨɞɪɨɛɧɵɟ ɞɚɧɧɵɟ;
x ɢɬɨɝɢ ɢɥɢ ɫɜɨɞɤɚ ɞɚɧɧɵɯ;
x ɭɬɜɟɪɠɞɟɧɢɟ ɢɥɢ ɩɨɞɩɢɫɢ;
x ɤɨɦɦɟɧɬɚɪɢɢ.
Ɋɢɫ. 7.4. Ɏɨɪɦɚ ɞɥɹ ɩɪɟɞɫɬɚɜɥɟɧɢɹ ɤɨɦɦɟɪɱɟɫɤɨɣ ɞɟɹɬɟɥɶɧɨɫɬɢ
ȼɨ ɦɧɨɝɢɯ ɨɪɝɚɧɢɡɚɰɢɹɯ, ɞɚɧɧɵɟ ɱɚɫɬɨ ɫɧɚɱɚɥɚ ɡɚɩɢɫɵɜɚɸɬɫɹ ɧɚ
ɛɭɦɚɠɧɵɯ ɮɨɪɦɚɯ ɢ ɡɚɬɟɦ ɩɨɡɠɟ ɡɚɧɨɫɹɬɫɹ ɜ ɩɪɢɤɥɚɞɧɵɟ ɫɢɫɬɟɦɵ. ɉɪɢ
ɩɪɨɟɤɬɢɪɨɜɚɧɢɢ ɦɚɤɟɬɨɜ ɞɥɹ ɡɚɩɢɫɢ ɢɥɢ ɜɵɜɨɞɚ ɧɚ ɷɤɪɚɧ ɢɧɮɨɪɦɚɰɢɢ ɜ
322
формах, основанных на бумажном представлении, это необходимо делать похожим образом насколько это возможно. Кроме того, экранные
формы для ввода данных в различных приложениях должны быть отформатированы единообразно, чтобы ускорить ввод данных и сократить количество ошибок. Рис. 7.5 показывает форму в компьютерном
представлении эквивалентную бумажной форме рис. 7.4.
Свежая выпечка
Заказ клиента
Сегодня: 15 Марта 2015
Номер заказа:000 000 334 157
Данные клиента
Номер клиента:
Наименование:
Адрес:
Город:
Индекс:
Код товара
234
157
097
391
128
Сдобушка
Кирова 25
Уссурийск
692509
Наименование
Гамбургер
Батон
Булочка
Пирожное
Количество
50
30
60
60
Цена Стоимость
19,00
950,00
15,00
450,00
7,50
450,00
16,00
900,00
ИТОГО
3650,00
6% СКИДКА
219,00
ИТОГО К ОПЛАТЕ 3431,00
Справка
Печать
Выбрать клиента
Рис. 7.5. Компьютерная форма заказа клиента
Еще одной проблемой при проектировании макета компьютерных
форм является дизайн навигации между полями. Так как мы можем
контролировать последовательность перемещения пользователя между полями, стандартный экранный поток навигации должен распространяться слева направо и сверху вниз так же, как когда мы работаем с бумажными формами. Например, рис. 7.6 противопоставляет перемещение между полями формы, используемой для записи деловых
контактов. Рис. 7.6а использует последовательность перемещения
323
слева-направо и сверху-вниз. Рис. 7.6б использует поток, который является не интуитивным. При необходимости, мы также должны группировать поля данных в логические категории с обозначениями, описывающими содержимое данной категории. Области экрана, не используемые для ввода данных или команд, должны быть недоступны
для пользователя.
Контактные деловые данные
Фамилия _______________
Имя _______________
Отчество _________
Адрес _________________________________________________
Адрес _________________________________________________
Телефон _______________________
Факс __________________________
Электронная почта ______________
Примечание
______________________________________________________________
______________________________________________________________
______________________________________________________________
а)
Контактные деловые данные
Фамилия _______________
Имя _______________
Отчество _________
Адрес _________________________________________________
Адрес _________________________________________________
Телефон _______________________
Факс __________________________
Электронная почта ______________
Примечание
______________________________________________________________
______________________________________________________________
______________________________________________________________
б)
Рис. 7.6. Сопоставление потока навигации в форме ввода данных
а) правильный поток между полями ввода данных;
б) неправильный поток между полями ввода данных
324
При проектировании процедур навигации в системе основными
проблемами являются гибкость и единообразие. Пользователи должны иметь возможность свободно двигаться вперед и назад, или к каким-либо нужным полям ввода данных. Пользователи должны иметь
также возможность перемещаться в каждой форме в аналогичной манере, или в подобной манере, насколько это возможно. Кроме того,
данные не должны, как правило, сохраняться постоянно в системе до
тех пор, пока пользователь не сделает явный запрос, чтобы сделать
это. Это позволяет пользователю отменить действие экрана ввода
данных, выполнить резервное копирование, или двигаться вперед без
ущерба для содержимого постоянных данных.
Единообразие распространяется и на выбор клавиш и команд.
Каждая клавиша или команда должна иметь только одну функцию, и
эта функция должна быть, по возможности, постоянной по всей системе и между системами. В зависимости от приложения, для обеспечения плавной навигации и ввода данных могут потребоваться различные виды функциональных возможностей. Табл. 7.1 содержит
список функциональных требований для обеспечения плавной и легкой навигации внутри формы.
Например, функциональный и единообразный по стилю интерфейс
обеспечит пользователей общими способами перемещения курсора
на разные места формы, редактирования символов и полей, перемещения между экранными формами и получения помощи. Эти функции могут быть предоставлены нажатием клавиш, мышью или операциями другого позиционирующего устройства, или выбором меню,
или активацией кнопки. Вполне возможно, что, для одного приложения все функциональные возможности, перечисленные в табл. 7.1,
могут не быть необходимыми для создания гибкого и единообразного
пользовательского интерфейса. Тем не менее, возможности, которые
используются, должны применяться единообразно для обеспечения
оптимальной пользовательской среды. Табл. 7.1 может служить в качестве контрольного листа, для проверки удобства дизайна пользовательского интерфейса.
325
Таблица 7.1
Функциональные возможности экрана ввода данных
Возможности управления курсором:
Переход курсора вперед к следующему полю данных
Переход курсора назад к предыдущему полю данных
Переход курсора на первое, последнее или какое-либо другое назначенное поле данных
Переход курсора вперед на один символ в поле
Переход курсора назад на один символ в поле
Возможности редактирования:
Удалить символ слева от курсора
Удалить символ под курсором
Удалить все поле
Удалить данные из всей формы (пустая форма)
Возможности выхода:
Передача экрана в прикладную программу
Перейдите в другой экран/форму
Подтвердить сохранение правок или перейти к другому экрану/форме
Возможности помощи:
Получить помощь о поле данных
Получить помощь о всем экране/форме
Структурирование ввода данных. При структурировании полей
ввода данных на форме следует учитывать несколько правил
(табл. 7.2). Первое правило является простым, но часто нарушаемым
проектировщиками. Чтобы свести к минимуму количество ошибок
при вводе данных и раздражение пользователей, никогда не требуйте
от пользователя вводить информацию, которая уже доступна в системе, или информацию, которая может быть легко вычислена системой.
Например, никогда не требуют от пользователя ввести текущую дату
и время, потому что каждое из этих значений может быть легко извлечено из внутреннего календаря и часов компьютерной системы.
326
Позволяя системе делать это, пользователь просто подтверждает, что
календарь и часы работают должным образом.
Таблица 7.2
Рекомендации для структурирования данных полей ввода
Правило
Ввод
Рекомендация
Никогда не требуйте данных, которые уже присутствуют в
системе или которые могут быть вычислены. Например, не
вводите данные о клиентах в форму заказа, если эти данные
могут быть получены из базы данных. Не вводите расширенные цены, которые могут быть вычислены из продаваемого
количества и цен за единицу.
Значения
Всегда при необходимости обеспечивайте значения по умолчапо умолчанию нию. Например, предполагаемую сегодняшнюю дату для новой
счета-фактуры, или используйте стандартную цену на товар,
если она не отменена.
Единицы
Обеспечивайте ясно тип данных, запрашиваемых для ввода.
Например, обозначьте количество в тоннах, рублях, и т.д.
Замещение
Используйте символ замещения при необходимости; например,
позволяйте пользователю искать значение в таблице или автоматически, заполняйте значение после того, как пользователь
введет достаточно существенных признаков.
Надписи
Всегда ставьте наименования полей, прилегающими к полю;
рис.7.7 варианты надписей.
Формат
Приводите примеры форматирования при необходимости;
например, автоматически показывайте стандартные встроенные символы, десятичные точки, символ кредита или знак доллара.
Выравнива- Автоматически выравнивай записи данных; числа должны
ние
быть выровнены по правому краю и по десятичным точкам, а
текст должен быть выровнен влево
Помощь/
Обеспечивайте контекстно-зависимую помощь, когда это
Справка
необходимо; например, обеспечьте горячую клавишу, такую
как клавиша Fl, которая открывает справочную систему в том
месте, которое наиболее тесно связанно с местом положения
курсора на дисплее.
327
В равной степени важны и другие правила. Например, предположим, что клиент банка выплачивает кредит по установленному графику с равными месячными платежами. Каждый месяц, когда платеж
посылается в банк, работник банка должен записать в систему обработки кредитов, что был получен платеж. При такой системе в
надлежащих случаях должны быть обеспечены значения по умолчанию для полей. Это означает, что только в тех случаях, если бы клиент оплатил больше или меньше запланированного количества, служащий должен был бы ввести данные в систему. Во всех других случаях, клерк мог бы просто убедиться, что платеж соответствует сумме
по умолчанию, предоставляемой системой, и нажать одну клавишу,
для подтверждения квитанции об оплате.
При вводе данных, пользователь также не должен быть обязан
указывать единицы измерения конкретной величины. Например,
пользователь не обязан указывать, что величина измеряется в рублях
или вес в тоннах. Формат поля и подсказка ввода данных должны ясно дать понять, тип запрашиваемых данных.
Другими словами, надпись для данных, которые будут вводиться,
должна находиться рядом с каждым полем данных. Из этой надписи
пользователю должно быть ясно, какой тип данных запрашивается
для ввода. Как и при отображении информации, все данные, введенные в форму, должны автоматически выравниваться в стандартный
формат (например, дата, время, деньги). Рис. 7.7 иллюстрирует несколько вариантов, подходящих для печатных форм. Для ввода данных с дисплеев, необходимо выделить область, в которую вводится
текст, с ясным указанием точного количества строк и количества
символов в каждой строке. Можно также использовать флажки или
радио-кнопки, чтобы пользователи могли выбрать стандартные текстовые ответы. Можно также использовать элементы управления
вводом данных, чтобы убедиться, что вводится надлежащий тип данных (символьных или цифровых). Контроль ввода данных обсуждается ниже.
328
Вариант
Линейная надпись
Пример
Номер телефона ( )
Надпись под полем
( )
Номер телефона
Надпись в рамке
Номер телефона
Разделение символов в надписи
Флажки с галочками
-
(
)
Номер телефона
Метод оплаты (отметить один)
Чек
Наличные
Кредитная карта
Рис. 7.7. Варианты ввода текста
Контроль ввода данных. Одной из задач проектирования интерфейса является сокращение ошибок при вводе данных. Поскольку
данные вводятся в информационную систему, должны быть приняты
меры для обеспечения того, чтобы они были достоверны. Системный
аналитик должен предвидеть типы ошибок, которые могут сделать
пользователи, и конструктивные особенностей в интерфейсе системы,
чтобы избежать, обнаружить и исправить все ошибки ввода данных.
В табл. 7.3 приведены несколько типов ошибок в данных. В сущности, ошибки в данных могут происходить из-за добавления дополнительных данных в поле, потери символов поля, занесении неправильных символов в поле, или перестановке одного или более символов в
поле.
Проектировщики систем разработали многочисленные проверки и
методы для перехвата неверных данных перед сохранением или передачей, улучшая, таким образом, вероятность того, что данные будут достоверны. Табл. 7.4 приводит обзор этих методов. Эти тесты и
методы часто включаются как в экраны ввода данных, так и в программы передачи межкомпьютерных данных.
Таблица 7.3
329
Источники ошибок данных
Ошибка данных
Добавление
Усечение
Замена символов
Изменение
порядка
Описание
Добавление дополнительных символов в поле.
Потеря символов в поле.
Ввод недопустимых данных в поле.
Перестановка последовательности одного или более
символов в поле.
Таблица 7.4
Тесты проверки и способы повышения
достоверности ввода данных
Тест проверки
Класс или композиция
Описание
Тест для обеспечения соответствия типа данных
требуемому (например, все числовые, все алфавитные или все алфавитно-цифровые).
Комбинация
Тест проверки значений комбинации нескольких
полей записи на логическое соответствие и смысл
(например, имеет ли смысл количество проданного для товара данного типа).
Ожидаемые
Тест проверки на соответствие поступивших данзначения
ных ожидаемым значениям (например, совпадение
с существующими именами заказчиков, суммой
платежа и т.п.).
Пропущенные данные Тест на присутствие элементов данных во всех полях записи (например, присутствует ли значения для
поля «количество» в каждой строке заказа клиента?)
Изображения/
Тест для обеспечения соответствия данных станШаблоны
дартному формату (например, на месте ли расположен дефис в идентификационном номере студента?)
Диапазон
Тест для обеспечения нахождения значения данного в диапазоне заданных значений (например,
находится ли средняя оценка студента в диапазоне
от 2,0 до 5,0).
Окончание табл. 7.4
330
Тест проверки
Обоснованность
Описание
Тест для проверки данных на обоснованность для
данной ситуации (например, ставка оплаты труда
для конкретного типа работника).
Цифры самопроверки Тест, в котором дополнительные цифры добавляются к цифровому полю, в котором его значение
вычисляется с использованием стандартной формулы.
Размер
Тест для проверки недостающего или превышающего количества символов в поле (например, количества символов номера лицевого счета для
оплаты услуг ЖКХ).
Значения
Тест проверки, что поступившие значения соответствуют множеству стандартных значений.
Практический опыт также показал, что гораздо легче исправить
ошибочные данные до того, как они будут запомнены для постоянного
хранения в системе. Онлайновые системы могут уведомить пользователя о проблемах ввода при их вводе. Когда данные обрабатываются в
онлайновом режиме одновременно с событием, то гораздо менее вероятно, что произойдут или будут не выявлены ошибки достоверности
данных. В онлайновой системе, используя многие из методов, описанных в табл. 7.4, большинство проблем могут быть легко идентифицированы и разрешены до постоянного сохранения данных в запоминающем
устройстве. Тем не менее, в системах, где входные данные сохраняются
и вводятся (или передаются) в пакетном режиме, выявление и уведомление об ошибках является более трудным. Системы пакетной обработки, однако, могут отказаться от неверных данных и сохранять их в
файле журнала для последующего разрешения.
Большинство тестов и методов, приведенных в таблице 7.4, широко и непосредственно используются. Некоторые из этих тестов могут
быть выполнены технологиями управления данными, такими как системы управления базами данных (СУБД), что гарантирует применение этих проверок для всех операций по поддержке данных. Если
331
СУБД не может выполнить эти проверочные тесты, то они должны
быть разработаны и встроены в прикладные программные модули.
В дополнение к проверке значений данных, введенных в систему,
должны быть установлены средства управления для подтверждения,
что все входные записи вводятся правильно, и что они обрабатываются
только один раз. Распространенным методом, используемым для повышения достоверности ввода партий данных, является создание контрольного следа всей последовательности ввода, обработки и хранения
данных. В таком контрольном следе, фактическая последовательность,
количество, время, местоположение источника, человек-оператор, и так
далее записываются в отдельный журнал транзакций в случаях ввода
данных или ошибки обработки. Если происходит ошибка, можно внести исправления путем анализа содержимого журнала. Подробные
журналы входных данных не только полезны для решения пакетных
ошибок при вводе данных и аудите системы, но они также служат в качестве мощного метода для выполнения резервного копирования и восстановления в случае катастрофического сбоя системы.
Обеспечение обратной связи. Когда мы говорим с собеседником,
мы бы ощущали беспокойство, если бы он не подавал нам обратной
связи, кивая и отвечая на вопросы и комментарии. Без действия обратной связи, мы были бы обеспокоены тем, что он нас не слушает.
Подобным образом, при проектировании интерфейсов системы,
обеспечение соответствующей обратной связи, является простым
способом получения более приятного взаимодействия пользователя.
Отсутствие обратной связи является верным способом, чтобы все сорвать и запутать. Существует три вида обратной связи системы:
x информация о состоянии;
x отклики с подсказкой;
x сообщения об ошибках и предупреждающие сообщения.
Информация о состоянии. Предоставление информации о состоянии является простым методом для постоянного информирования
пользователей о том, что происходит внутри системы. Например, соответствующая информация о состоянии, такая как отображение текуще332
го имени клиента или времени, размещение соответствующих названий
в меню или на экране, или идентификация количества экранов, следующих за текущим (например, экран 1 из 3), обеспечивает необходимую
обратную связь с пользователем. Предоставление информации о состоянии в процессе обработки операций особенно важно, если операция
занимает больше времени, чем секунду или две. Например, при открытии файла можно отобразить «Пожалуйста, подождите пока открывается файл», или, при выполнении больших вычислений – высветить для
пользователя сообщение «Working ...». Кроме того, важно сообщить
пользователю, что, кроме выполнения заданной работы, система восприняла ввод пользователя, и что этот ввод был осуществлен в правильной форме. Иногда важно предоставить пользователю возможность получения большей обратной связи. Например, функциональная
клавиша могла бы переключаться между высвечиванием сообщения
«Working ...» и более конкретной информацией по мере завершения
каждого промежуточного этапа обработки/вычислений. Предоставление информации о состоянии убедит пользователей, что все в порядке,
и позволит им чувствовать себя владельцем системы, а не наоборот.
Отклики с подсказкой. Второй способ обратной связи является
отображение откликов с подсказкой. Когда проектируется подсказка
для информирования или действия пользователя, то полезно быть в
ней конкретным. Например, предположим, что система обратилась к
пользователям со следующим запросом:
READYFOR INPUT: _________
При такой подсказке, проектировщик предполагает, что пользователь знает точно, что ему вводить. Однако более удобным был бы дизайн более конкретного отклика, обеспечивая, возможно, например,
значение по умолчанию или информацию о формате. Улучшенный
запрос подсказки мог бы выглядеть следующим образом:
Введите номер лицевого счета, (123-4567-8):___-____-_
Сообщения об ошибках и предупреждающие сообщения. Последний метод применяется для обеспечения обратной связи системы с помощью сообщения об ошибке и предупреждения. Практический опыт
333
показал, что несколько простых правил, могут значительно ее улучшить.
Во-первых, сообщения должны быть конкретными и свободными от
ошибок кодов и жаргона. Кроме того, сообщения никогда не должны ругать пользователя и должны пытаться помочь пользователю в разрешении трудностей. Например, сообщение могло бы содержать текст: «Отсутствует запись о клиенте с таким идентификатором. Убедитесь, что
цифры не были переставлены». Сообщения должны быть выражены в
терминах пользователя, а не компьютера. Следовательно, такие термины, как «конец файла», «ошибка в/в диска», «защищено от записи»,
можно рассматривать как слишком технические и не полезные для многих пользователей. Составные или многократные сообщения могут увеличить пользу, при этом пользователь может получить более подробные
пояснения при желании или необходимости. Кроме того, сообщения об
ошибках должны появиться каждый раз примерно в том же формате и
размещении таким образом, чтобы они распознавались в качестве сообщений об ошибках, а не как какой-либо другой информации. Примеры
хороших и плохих сообщений приведены в табл. 7.5.
Таблица 7.5
Примеры плохих и улучшенных сообщений об ошибках
Плохие сообщения об ошибке
Улучшенные сообщения об ошибках
ОШИБКА ОТКРЫТИЯ ФАЙЛА 56 Имя введенного файла не найдено.
Нажмите F2 для просмотра допустимых
имен файлов.
ОШИБОЧНЫЙ ВЫБОР
Пожалуйста, введите опцию из меню.
ОШИБКА ВВОДА ДАННЫХ
Согласно ограничениям ввода, значение находится вне пределов допустимых значений. Нажмите F9 для просмотра допустимых значений.
ОШИБКА СОЗДАНИЯ ФАЙЛА
Имя введенного файла уже существует.
Нажмите F10, если вы хотите перезаписать файл. Нажмите F2 если вы хотите
сохранить файл с другим именем.
334
Используя эти принципы, мы можем получить полезную обратную
связь в своих проектах. Особым типом обратной связи является передача ответов на запросы пользователей о помощи. Эта важная тема
описана ниже.
Обеспечение помощи (Справка). Проектирование помощи является одним из самых важных вопросов, который стоит перед разработчиками, при создании интерфейса. При проектировании помощи, мы
должны поставить себя на место пользователя. Обращаясь за помощью,
пользователь, скорее всего, не знает, что делать дальше, не знает то, что
запрашивать, или не знает, как запрашивающая информация должна
быть отформатирована. Пользователь, запрашивающий помощь, во
многом подобен терпящему бедствие судну, отправляющему SOS.
В табл. 7.6, предоставлены рекомендации SOS для проектирования системной помощи: простота, организация и демонстрация.
Таблица 7.6
Рекомендации для проектирования полезной справки
Рекомендация
Простота
Организация
Демонстрация
Объяснение
Используйте короткие, простые формулировки общепринятого применения и полные предложения.
Предоставляйте пользователям только то, что они хотят узнать, с возможностью обеспечения дополнительной информации.
Используйте упорядоченные перечисления для разделения информации на управляемые части.
Обеспечьте примеры правильного использования и
результатов такого использования.
Первая из рекомендаций, простота, предполагает, что сообщения
помощи должны быть короткими и по существу, и использовать понятные слова. Это приводит ко второй рекомендации, организация, это
означает, что сообщения помощи должны быть написаны так, чтобы
информация могла быть легко воспринята пользователями. Практиче335
ский опыт оказал, что длинные абзацы текста часто трудны для понимания людьми. Лучший дизайн организует многословную информацию
способом удобным для восприятия пользователями за счет использования маркированных и упорядоченных списков. Наконец, часто бывает
полезным, явно демонстрировать пользователям, как выполнить операцию и результат процедурных шагов.
Многие коммерчески доступные системы предоставляют обширную справочную систему. Многие из них также разработаны таким
образом, что пользователи могут изменять уровень детализации. Помощь может быть предоставлена на системном уровне, на уровне экрана или формы и на уровне отдельного поля. Способность обеспечить
помощь на уровне поля, часто называется «контекстно-зависимой» помощью. Для некоторых приложений обеспечение контекстнозависимой помощи для всех опций системы является огромным мероприятием, которое практически является проектом само по себе. Если
вы решили разработать обширную справочную систему со многими
уровнями детализации, вы должны быть уверены, что точно знаете, в
чем требуется помочь пользователю, или ваши усилия могут запутать
пользователей больше, чем помочь им. После ухода с экрана справки
помощи пользователи всегда должны вернуться туда, где они были до
запроса о помощи. Если вы будете следовать этим простым рекомендациям, вероятно, создадите очень удобную систему помощи.
Как и в конструировании меню, многие среды программирования
обеспечивают мощные инструменты для разработки справочной системы. Например, среда Microsoft HTML Help позволяет быстро построить
гипертекстовые справочные системы. В этой среде, используется текстовый редактор для создания страниц справки, которые могут быть
легко связаны с другими страницами, содержащими родственную или
более конкретную информацию. Связи создаются путем встраивания
специальных символов в текстовый документ, что создает гипертекстовые кнопки, то есть прямые связи к дополнительной информации.
Microsoft HTML Help преобразует текстовый документ в гипертекстовый. Например, на рис. 7.8 показан экран справки браузера Firefox на
336
основе гипертекста. Справочные системы на основе гипертекста стали
стандартом для большинства коммерческих приложений. Это произошло по двум основным причинам. Во-первых, стандартизация системной справки в различных приложениях облегчает обучение пользователей. Во-вторых, гипертекст позволяет пользователям осуществлять избирательный доступ того уровня помощи в которой они нуждаются,
облегчая обеспечение эффективной помощи, как новичкам, так и опытным пользователям в рамках той же системы.
Рис. 7.8. Справочная система Firefox, основанная на гипертексте
Процесс проектирования общей последовательности, которой будут следовать пользователи, взаимодействуя с информационной системой, называется проектированием диалога. Диалог представляет
собой последовательность, в которой информация отображается
пользователю, и получается от пользователя. Роль проектировщика
состоит в выборе наиболее подходящих методов взаимодействия и
337
устройств, а также в определении условий, при которых информация
отображается пользователю и получается от него. Процесс проектирования диалога состоит из трех основных этапов:
I. проектирование последовательности диалога;
2. создание прототипа;
3. оценка простоты использования.
7.2.2. Проектирование диалога
В табл. 7.7 представлены общие правила, которые следует соблюдать при проектировании диалога. Чтобы диалог имел высокую степень простоты использования, он должен быть единообразным по
форме, функции и стилю. Все остальные правила проектирования диалога подчинены принципу единообразия. Например, эффективность
обработки ошибок или обеспечения обратной связи в значительной
степени зависит от соблюденного единообразия в дизайне. Если система не будет единообразно обрабатывать ошибки, пользователь часто будет в растерянности, почему происходят некоторые явления.
Одна из таких рекомендаций связана с удалением данных из базы
данных или файла (смотри отмена записи в табл. 7.7). Это хорошее
правило, отображать информацию, которая будет удалена, до совершения постоянного изменения в файле. Например, если работник
службы обслуживания клиентов хотел бы удалить клиента из базы
данных, система должна была бы спросить только идентификатор
клиента для того, чтобы найти правильную учетную запись. После
того, как она найдена, и, прежде чем разрешить подтверждение удаления, система должна была бы отобразить информацию этой учетной записи. Для действий, осуществляющих постоянные изменения в
файлах данных системы, и, когда действие не относятся не к общепринятым, многие проектировщики систем используют метод двойного подтверждения. С помощью этого метода пользователи должны
подтвердить свое намерение дважды до того как им будет позволено
его выполнение.
338
Таблица 7.7
Рекомендации для проектирования
человеко-компьютерного диалога
Рекомендации
Объяснение
Единообразие
Диалоги должны представлять единообразную последовательность действий, нажатий клавиш и терминологии.
Например, одни и те же обозначения должны быть использованы для одних и тех же операций на всех экранных формах, расположение одной и той же информации
также должно быть одинаковым на всех экранных формах.
«Горячая клави- Разрешить опытным пользователям сокращать ввод с
ша» и последова- помощью специальных клавиш (например, CTRL-C для
тельность
копирования выделенного текста). Должна соблюдаться
естественная последовательность шагов (например,
ввод фамилии до имени, если это необходимо).
Обратная связь
Для каждого действия пользователя должна быть обеспечена обратная связь (Например, подтвердить, что запись была добавлена, а не просто высветить еще одну
пустую форму на экране).
Замыкание
Диалоги должны быть логически сгруппированы и
иметь начало, середину и конец (например, последний в
последовательности экран должен указывать, что больше экранов нет).
Обработка оши- Все ошибки должны быть выявлены и зарегистрировабок
ны; должны быть даны предложения о том, как следует
действовать (например, объяснить, почему такие ошибки происходят, и то, что может сделать пользователь,
чтобы исправить ошибку). Для определенных ответов
должны быть приняты синонимы (например, допускается или 't», «T» или TRUE»).
Отмена
Диалоги должны, по возможности, позволять пользователю отменить действия (например, отменить удаление); данные не должны удаляться без подтверждения
(например, отображать все данные для записи, которую
пользователь обозначил для удаления).
339
Окончание табл. 7.7
Контроль
Легкость
Диалоги должны создать пользователю (особенно
опытным пользователям) ощущения контроля над системой (например, обеспечить совместимое время отклика в темпе, приемлемом для пользователя).
Процесс ввода информации и перемещения между
экранами должен быть для пользователей простым
(например, обеспечить средства для перемещения вперед, назад, и конкретных экранов, таких как первый и
последний).
Проектирование последовательности диалога. Первым шагом в
проектировании диалога является определение последовательности.
Другими словами, необходимо сначала получить представление о
том, как пользователи могли бы взаимодействовать с системой. Это
означает, что при проектировании диалогов должно быть четкое
представление о пользователе, задаче, технологических характеристиках и окружении.
Предположим, что менеджер по маркетингу хочет, чтобы его персонал имел возможность проведения анализа деятельности обработки
транзакций для любого клиента компании с начала года до текущей
даты. После разговора проектировщика с менеджером оба согласны,
что типичный диалог для получения этой информации между пользователем и клиентской информационной системой, мог бы выглядеть
следующим образом.
1. Запрос на просмотр индивидуальной информации о клиенте.
2. Указать интересующего клиента.
3. Выбрать экранную форму «Сводка транзакций с начала года до
текущей даты».
4. Проанализировать информацию о клиенте.
5. Выход из системы
Проектировщик, получив представление о том, как пользователь
желает использовать систему, может затем трансформировать эти виды действий в формальную спецификацию диалога.
340
Формальным методом для проектирования и представления диалогов является схематическое изображение диалога. Схемы или диаграммы диалога (схема потока диалога) используют только один символ - прямоугольник с тремя разделами. Каждый прямоугольник схемы представляет одно дисплейное изображение (которое может быть
полным экраном, или конкретной формой, или окном) в пределах
диалога (рис. 7.9). Все три секции прямоугольника используются следующим образом:
1. Верхняя: Содержит уникальный идентификационный номер дисплея, используемый для ссылок на него другими дисплеями или дисплейными изображениями.
2. Средняя: Содержит имя или описание дисплейного изображения.
3. Нижняя: Содержит ссылочные номера дисплейных изображений,
к которым имеется доступ от текущего дисплея.
Уникальный
ссылочный
номер дисплея
Имя или
описание
дисплейной
формы
Верх
Средина
Номера
дисплеев
возврата
Низ
Рис. 7.9. Секции символа дисплея
для схематического изображения диалога
Все линии, соединяющие прямоугольники внутри диаграммы потока диалога, могут быть двунаправленным и, таким образом, отсутствует необходимость в стрелках, чтобы указывать направление. Это
означает, что пользователи могут перемещаться вперед и назад между смежными дисплеями. Если необходимо применить только однонаправленные потоки в диалоге, то на одном конце соединяющей ли341
нии должны быть размещены стрелки. В диалоговой схеме можно
легко представить последовательность дисплеев, выбор одного дисплея из другого, или повторное использование одного дисплея
(например, дисплея ввода данных). Эти три понятия последовательность, выбор и итерация проиллюстрированы на рис. 7.10.
Дисплей А
Последовательность
Дисплей Б
Итерация
Дисплей В
Дисплей Г
Дисплей Д
Выбор
Рис. 7.10. Диаграмма потока диалога, иллюстрирующая
последовательность, выбор и итерацию
Продолжая пример системы «Свежая выпечка», рис. 7.11 показывает схему потока диалога информационной системы для производственной бригады. На этой диаграмме проектировщик изобразил человеко-компьютерное взаимодействие производственной бригады в
лице ее уполномоченного лица в контексте всей информационной системы. Пользователь должен сначала получить доступ к системе через процедуру входа в систему (пункт 0).
342
0
Экран
Log In
Система
1
Главное меню
0, Система
2
3
4
Получение
сырья
Формирование
лота доставки
Передача
продукции на
склад
1
1
1
2.1
2.2
3.1
Добавление
сырья
Подтверждение
получения
сырья
Добавление
лота доставки
2
2
3
2.1.1
2.2.1
3.1.1
Подтверждение
добавления
Оформление
накладной на
перемещение
сырья
2.1
2.2
4.1
4.1.1
Добавление
лота доставки
Подтверждение
добавления
4
4.1
3.1.2
3.1.3
Добавление
продукта
Удаление
продукта
Завершение
формирования
лота
доставки
3.1
3.1
3.1
3.1.1.1
3.1.2.1
3.1.3.1
Подтверждение
добавления
Подтверждение
удаления
Подтверждение
завершения
формирования
лота
3.1.1
3.1.2
3.1.3
4.2.1
4.2
Оформление
накладной на
перемещение
товара
Подтверждение
окончания
передачи
4.2
4
Рис. 7.11. Схема диалога производственной бригады
информационной системы «Свежая выпечка»
343
Если вход прошел успешно, отображается главное меню, которое
имеет три позиции (пункт 1). Для того чтобы приступить к начальной
фазе производства продукции и получить сырье в составе и в количестве, определенном производственным расписанием, пользователь
выбирает позицию «Получение сырья» (пункт 2). Получая последовательно требуемое сырье, он действует в соответствии с указаниями
дисплея (пункт 2.1), подтверждая выполнение каждого действия в
дисплее пункт (2.1.1). Завершив получение сырья на очередную партию продукции, он подтверждает этот факт (пункт 2.2.) и оформляет
накладную на перемещение принятого сырья (пункт 2.2.1).
Для того чтобы подготовить готовую продукцию к отправке и разместить ее в транспортировочном лотке, пользователь выбирает
пункт 3, и затем пункт 3.1 с которого начинается заполнение продукцией на каждого лотка. Заполнение транспортировочного лотка состоит в добавлении в него продукции (пункты 3.1.1 и 3.1.1.1) и исправлении совершенных при этом ошибочных действий (пункты 3.1.2
и 3.1.2.1). Завершение формирования лота доставки оформляется с
применением экранов 3.1.3 и 3.1.3.1.
Сформированные лоты доставки передаются на склад для временного размещения готовой продукции. Операция передачи выполняется по каждому лоту в отдельности (пункты 4.1 и 4.1.1). Завершение
передачи сопровождается оформлением соответствующего документа
с применением соответственно экранных форм 4.2 и 4.2.1.
Создание макета и оценка простоты использования. Создание
макета (прототипа) и оценка простоты использования часто является
дополнительным мероприятием. Некоторые системы могут быть
очень простыми; другие могут быть более сложными, но являться
расширениями действующих систем, где уже были установлены
стандарты диалога и дисплейных изображений. В любом из этих случаев не обязательно строить макеты и проводить формальную оценку. Тем не менее, для многих других систем создание дисплеев макета, а затем проведение оценки диалога может быть важным. Это может принести многочисленные дивиденды позже в жизненном цикле
344
разработки системы (например, это может облегчить внедрение системы или обучение пользователей в системе, которую они уже видели и использовали).
Создание макета дисплеев часто является относительно легкой деятельностью, если используются графические среды разработки, такие как Microsoft Visual Studio. Некоторые среды разработки систем
включают в себя простые в использовании утилиты проектирования
входа и выхода. Инструменты называемые «prototypers» или «demo
builders» предоставляют возможность быстро разработать дисплеи и
показать, как будет работать интерфейс в рамках полной системы.
Эти демонстрационные системы позволяют пользователям вводить
данные и перемещаться по дисплеям, как если бы использовалась реальная система. Такие мероприятия полезны не только для того, чтобы показать, как будет выглядеть и ощущаться интерфейс, но они
также полезны для оценки простоты использования и для выполнения
обучение пользователей задолго до того как будут завершены реальные системы. Следующий раздел расширяет наше представление о
проектировании интерфейса и диалога, рассматривая вопросы, характерные для графических сред пользовательских интерфейсов.
7.2.3. Проектирование интерфейсов и диалогов
в графической среде
Среды графических пользовательских интерфейсов (Graphic User Interface, GUI) стали де-факто стандартом для человеко-компьютерного
взаимодействия. Хотя все рекомендации проектирования интерфейса и
диалога, представленные ранее, распространяются на проектирование
графических интерфейсов, должны быть также рассмотрены дополнительные вопросы, которые являются уникальными для этих сред.
В этом разделе рассматриваются некоторые из этих вопросов.
Вопросы проектирования графического интерфейса. При проектировании графического интерфейса пользователя приложений,
действующих в окружении операционной среды, такой как Microsoft
345
Windows или Apple Macintosh, должны быть рассмотрены многочисленные факторы. Некоторые факторы являются общими для всех сред
GUI, в то время как другие являются специфическими для отдельных
сред. Данный раздел не рассматривает тонкости и детали какойнибудь из отдельных сред. Вместо этого, раздел сосредотачивается на
нескольких общих истинах, которые опытные проектировщики считают имеющими решающее значение для проектирования пригодных
для использования графических интерфейсов. В большинстве дискуссий по программированию GUI неоднократно появляются два правила, определяющие первый начинающий шаг на пути формирования
эффективного GUI проектировщика: стать пользователем-экспертом
среды GUI; понимать имеющиеся ресурсы и как они могут быть использованы.
Первое правило должно быть очевидным. Наибольшие усилия проектирования в стандартной среде операционной среды состоят в том в том,
что стандарты для поведения большинства операций систем уже определены. Например, как вырезать и вставить, настроить принтер по умолчанию, дизайн меню, либо назначить команды для функций, - все это было
стандартизировано, как в пределах приложений, так и между ними. Это
позволяет опытным пользователям одного приложения, основанного на
GUI, легко освоить новое приложение. Таким образом, для того, чтобы
спроектировать эффективные интерфейсы в этих условиях, необходимо
сначала понять, как были разработаны другие приложения. Таким образом, можно принять установленные уже стандарты для создания собственных GUI приложений, создающих подобный эффект «впечатления и
ощущения» (один из принципов оценки степени оригинальности программ) при их использовании. Непринятие стандартных соглашений в
данной среде приведет к созданию системы, которая, скорее всего, разочарует и запутает пользователей.
Второе правило, понимать имеющиеся ресурсы и как они могут быть
использованы - это гораздо сложнее. Например, в Windows вы можете
использовать меню, формы, поля и флажки многими способами. На самом деле, гибкость, с которой эти ресурсы могут быть использованы, в
346
сравнении со сложившимися стандартами фактического использования
этих ресурсов большинством проектировщиков делает дизайн особенно
сложным. Например, у вас есть возможность спроектировать меню, используя текст, полностью представленный заглавными буквами, поставив
несколько слов в верхней строке меню, и другие нестандартные условности. Тем не менее, стандарты для проектирования меню требуют, чтобы
пункты меню верхнего уровня состояли из одного слова и следовали в
определенном порядке. Для проектирования меню были также созданы
многие другие стандарты (смотри рис. 7.12 для иллюстрации многих из
этих стандартов). Несоблюдение стандартных правил проектирования,
вероятно, будет сбивать с толку пользователей.
Элемент меню «Файл»всегда располагается первым
Меню «Правка» всегда располагается вторым
Меню «Справка» всегда располагается последним
Заполненная окружность означает, что
выбран элемент или включен режим
Многоточие (…) указывает, что при
выборе появится всплывающее меню
Правая стрелка указывает, что при
выборе элемента появится подменю
Отсутствие пометки правее пункта указывает, что
при выборе будет выполнена команда
Рис. 7.12. Стандарты проектирования
графического интерфейса пользователя
347
В графических интерфейсах пользователя информация запрашивается посредством размещения формы или окна на экране визуального
дисплея. Как и меню, формы могут также иметь множество свойств
(табл. 7.8). Например, свойства форм определяют, является ли форма
изменяемой или перемещаемой после ее открывания. Так как свойства определяют, как пользователи могут на самом деле работать с
формой, эффективное применение свойств является основой для достижения простоты использования. Это означает, что в дополнение к
проектированию макета формы, необходимо также определить «индивидуальность» формы с характерными свойствами. К счастью, для
проектирования GUI были разработаны многочисленные инструменты, которые позволяют «визуально» проектировать формы и интерактивно назначать свойства. Интерактивные средства проектирования
графического пользовательского интерфейса значительно облегчили
процесс их проектирования и создания.
Таблица 7.8
Общие свойства Windows и Forms в среде GUI,
которые могут быть активными или не активными
Свойство
Модальность
Объяснение
Требует от пользователей выполнить требование до действия (например, необходимость отменить или сохранения до закрытия окна).
Изменяемость Позволяет пользователям изменять размер окна или
формы (например, чтобы освободить место, чтобы увидеть другие окна, которые также на экране).
Подвижность Позволяет пользователям перемещать окно или форму
(например, чтобы увидеть еще одно окно).
Максимизация Позволяет пользователям расширить окно или форму в
экране до полноразмерной (например, во избежание отвлечения от всех других активных окон или форм).
Минимизация Позволяет пользователям сжать окно или форму до
иконки (например, чтобы убрать окно во время работы с
другими активными окнами).
Системное
Позволяет окну или форме также иметь системное меню
меню
для прямого доступа к функциям системного уровня
(например, чтобы сохранить или скопировать данные).
348
Вопросы проектирования диалога в графической среде. При проектировании диалога, цель проектировщика состоит в установлении последовательности дисплеев (полноэкранных или оконных), с которыми
будут сталкиваться пользователи при работе с системой. Во многих средах GUI, этот процесс может быть немного более сложным, благодаря
способности графического интерфейса пользователя приостанавливать
действия (без завершения запроса на информацию или приложения в целом) и переключаться на другое приложение или задачу. Например, в
Microsoft Word, проверка орфографии выполняется независимо от общего текстового процессора. Это означает, что можно легко переключаться
между проверкой орфографии и текстовым процессором, не выходя ни
из одного из них. Наоборот, при выборе операции печати можно либо
инициировать печать, либо прервать этот запрос, прежде чем снова обратиться к текстовому процессору. Это пример концепции «модальности», описанной в таблице 7.8. В графическом интерфейсе пользователя
модальным называется окно, которое блокирует работу пользователя с
родительским приложением до тех пор, пока пользователь это окно не
закроет. Модальными преимущественно реализованы диалоговые окна.
Также модальные окна часто используются для привлечения внимания
пользователя к важному событию или критической ситуации. Таким образом, среда типа Windows позволяет создавать формы, которые либо
требуют, чтобы пользователь, либо завершил выполнение запроса
(например, печать) до другого действия обработки, либо избирательно
выбрал завершение текущего действия, прежде чем приступить к следующему. Создаваемые диалоги, позволяющие пользователю переходить от приложения к приложению или от модуля к модулю в данном
приложении, требуют, чтобы дизайн диалогов был тщательно продуман.
Один простой способ справиться со сложностью проектирования
передовых графических интерфейсов состоит в требовании от пользователей, чтобы они всегда завершали все запросы на получение информации, прежде чем приступали к другим действиям. Для такого
дизайна метод схематического изображения диалога является адекватным средством проектирования. Это, однако, заставляет систему дей349
ствовать способом похожим на традиционную (не GUI) среду, где последовательность дисплеев жестко контролируется. Недостатком такого подхода будет невозможность получения выигрыша на возможностях этих сред в переключении между задачами. Следовательно, проектирование диалогов в средах, где последовательность между дисплеями не может быть предопределена, выдвигает значительные проблемы для проектировщика. Использование таких инструментов, как
схематическое изображение диалога, помогает аналитикам лучше
управлять сложностью проектирования графических интерфейсов.
Ключевые термины
SQL
Администратор базы данных
Администратор данных
Аналитик данных
Архитектор базы данных
Архитектура данных
База данных
Взаимодействие на естественном
языке
Взаимодействие на языке команд
Взаимодействие, основанное на
меню
Взаимодействие, основанное на
формах
Всплывающее меню
Внешний ключ
Вторичный ключ
Диалог
Запись
Запись фиксированной длины
Имя роли
Интерфейс
Метаданные
Ниспадающее меню
Нормализация
Объектно-ориентированное взаимодействие
Операционные таблицы
Описательные поля
Пиктограмма
Первичный ключ
Персональная база данных
Поле
Распределение данных
Реляционная таблица
Реплицирование данных
Система управления базами данных
Схема базы данных
Схематическое изображение диалога
Триггер
Хранимая процедура
Целостность домена
Целостность ключа
Язык манипулирования данными
Язык определения данных
350
Контрольные вопросы
1. Различие между традиционными файлами и базами данных.
2. Что такое база данных? В чем состоит различие между производственной базой данных и персональной базой данных?
3. Объясните преимущества и недостатки традиционных файлов
относительно баз данных.
4. Дайте определение терминам поле, запись, файл.
5. Различия между первичным, вторичным и внешним ключом.
6. Определите различия между и администратором базы данных и
администратором данных. Какое существует отношение между этими
должностями и системным аналитиком?
7. Кратко объясните различие между языком определения данных,
базовым языком программирования и языком манипулирования данными.
8. Перечислите и кратко опишите три операции для манипулирования данными таблиц.
9. Приведите три характеристики хорошей модели данных.
10. Перечислите и кратко опишите три шага нормализации.
11. Сопоставьте следующие термины:
а. диалог, интерфейс;
б. взаимодействие на языке команд, взаимодействие на основе
форм, меню ориентированное взаимодействие, взаимодействие на естественном языке, объектно-ориентированное взаимодействие;
в. ниспадающее меню, всплывающее меню.
12. Опишите процесс проектирования интерфейсов и диалогов. Какие результаты создают эти процессы? Эти результаты такие же, как и
во всех других проектах систем? Почему да, и почему нет?
13. Опишите пять методов взаимодействия с системой. Является ли
один метод лучше, чем все другие?
14. Опишите общие рекомендации для проектирования меню. Существуют ли какие-нибудь случаи, когда будет более удобно нарушить
эти рекомендации?
351
15. Перечислите и опишите основные разделы типичной деловой
формы. Имеют ли компьютерные и традиционные бумажные формы
одинаковые компоненты?
16. Перечислите и опишите функциональные возможности необходимые на интерфейсе для эффективного ввода и навигации. Какие возможности являются наиболее важными?
17. Опишите общие руководства для структурирования полей ввода
данных. Думаете ли вы, что существуют случаи, когда лучше будет
нарушить эти принципы?
18. Опишите четыре типа ошибок данных.
19. Опишите методы, используемые для улучшения проверки ввода
данных.
20. Опишите типы обратной связи системы. Является ли какаянибудь форма обратной связи более важной, чем другие?
21. Опишите общие принципы для проектирования удобной в использовании справки помощи. Думаете ли вы, что существуют случаи,
когда лучше будет нарушить эти принципы?
22. Каким шагам необходимо следовать при проектировании диалога?
23. Опишите свойства окон и форм в среде GUI. Какое свойство вы
считаете наиболее важным?
24. Перечислите и опишите общие ошибки проектирования интерфейса и диалога, обнаруженные вами на Web-сайтах?
ЗАКЛЮЧЕНИЕ
Современный уровень развития технологий и всевозрастающая
конкуренция выдвигают высокие требования к проведению интеграции и автоматизации компаний. Информационные системы сегодня,
являясь стратегическим оружием, призваны обеспечивать стабильность экономического роста и конкурентоспособность компаний. Несмотря на то, что в стоимостном выражении затраты на осуществление полного комплекса таких работ уже достигают сорока процентов
инвестиций, результативность ИТ разработок во многом оставляет
желать лучшего. При этом существующий потенциал информационных технологий во многом недоиспользуется. Поэтому при создании
информационных систем разработчикам очень важно хорошо представлять и уметь применять передовые положения теории и практики
разработки систем, которые охватывают архитектуру, методологии,
CASE средства разработки и методы моделирования на этапах разработки систем.
Тема архитектуры информационных систем в настоящее время
становится все более актуальной. Первоначальное формальное определение фреймворка архитектуры информационных систем 1980-х гг.
эволюционировало в достаточно мощные современные фреймворки
архитектуры предприятия ZACHMAN, TOGAF, DoDAF, MODAF,
IBM, NATO, Federal Enterprise и множество других. Более точно, эти
фреймворки являются онтологиями – теорией существования ключевых компонент объекта и его описательных моделей. Применение
подобных фреймворков является стратегически важным, так как они
способствуют высокому качеству и бесшовности интеграции самого
предприятия и его информационной системы вне зависимости от используемых технологических платформ реализации. Фреймворки не
являются методологиями для создания и внедрения.
Методологии разработки информационных систем – это, скорее,
рекомендованный набор философских подходов, фаз, процедур, правил, методов, средств, документации, менеджмента и обучения для
353
разработчиков информационных систем. Впервые появившись в
1970-х г., сегодня они уже представлены образцами третьего поколения, реализованными в системах автоматизации разработки информационных систем. Такие современные средства CASE обеспечивают
сквозную разработку информационных систем практически на всех
этапах жизненного цикла, начиная с этапа стратегического планирования и заканчивая автоматической генерацией программного кода
приложений. Накопление всех результатов разработки, последовательно получаемых на этапах жизненного цикла, а также использование
этих результатов на последующих этапах осуществляется при помощи
электронного репозитория CASE средства. Обеспечивая создание целевой системы, CASE средства существенно повышают мобильность и
снижают расходы разработки. Таким образом, сформулированный вначале 1990-х гг. амбициозный тезис «Разработка приложений без программистов» является сегодня очевидной реальностью.
Модели и моделирование являются главными инструментами абстрактного представления информационной системы на фазах разработки до тех пор, пока она не будет специфицирована в виде воспринимаемых компьютерной системой кодов. Фреймворк архитектуры
информационной системы, представленный на рис. 1.5, обосновывает
необходимость применения в процессе разработки 24 абстрактных
моделей компонентов информационной системы, не включая языки
спецификаций инструментальных системных средств нижнего уровня. Кроме того правила инфраструктуры, определяющие отношения
между этими моделями, привносят определенные ограничения на создаваемые модели, обеспечивая их согласованность между собой и
совместимость. Это, в свою очередь, увеличивает прогрессивно количество необходимых формализмов для создаваемых абстракций.
Наиболее широко известными и применяемыми видами моделирования систем является моделирование функций, организации людских
ресурсов, процессов, данных, интерфейсов, диалогов, а также применение различных матриц. Упрощенно, следование по этапам траектории, определяемой методологией, разработка моделей на основе
354
входных данных на каждом из этапов и согласование моделей между
собой определяют процесс разработки системы. Этот процесс в итоге
завершается генерацией кодов на языках средств разработки программного обеспечения.
Процесс разработки информационных систем не может полагаться
на авось. Успешная разработка системы руководствуется некоторыми
базовыми фундаментальными принципами. Существует восемь
принципов, которые должны лежать в основе любой разработки. Эти
принципы, направляют разработку на реальные проблемы компании,
позволяют снизить или устранить риски, определяют этапы и объекты разработки на каждом из этапов, а также последовательность и отношения взаимосвязи между этапами, устанавливают стандарты для
совместимости разработок и документации. Причисляют системы к
капитальным вложениям компании, обосновывая тем самым необходимость проведения анализа выгодности или целесообразности затрат в ходе разработки. Кроме того они требуют не бояться отмены
или пересмотра масштаба проекта, предлагая подход приростного
обязательства и переоценку проекта в контрольных точках. Определяют применение подхода «разделяй и властвуй» для учета возможной динамики проекта и упрощения процесса решения проблемы; а
также обосновывают необходимость придания свойств гибкости и
адаптируемости разрабатываемой системе.
Стратегическое планирование является одной из начальных фаз
разработки системы. Оно обеспечивает необходимые установки корпоративного стратегического планирования для ре-инженеринга деятельности компании и разработки согласованной с ним информационной системы предприятия. Разрабатываемая при этом система будет являться целевой, так как архитектура системы предприятия становится согласованной с такими основными факторами стратегического планирования предприятия, как миссия, цели, конкурентная
стратегия и ключевые факторы успеха. Результаты планирования,
представляющие согласованные между собой модели компонентов
системы самого высокого уровня, сохраняются в электронном репо355
зитории CASE средства и используются в качестве входных данных
на последующих этапах разработки.
Анализ является фазой жизненного цикла разработки систем. Фаза
анализа в жизненном цикле занимает место между предшествующей
ей фазой планирования информационной системы и следующей за
ней фазой проектирования системы. Таким образом, получая на своем входе результаты планирования системы, фаза анализа системы
должна выработать и представить на своем выходе все спецификации
и модели, достаточные для проведения проектирования будущей системы. Цель анализа заключается в определении информации и сервисов информационной обработки, необходимой для поддержки выбранных целей и функций организации. Анализ систем связан со значительным количеством усилий и затрат. Многие ошибки в разработанных системах являются прямым следствием неадекватно приложенных усилий на этапах анализа. Анализ часто разделяют на две части, чтобы сделать этот процесс более легким в понимании: определение требований и структурирование требований. Разрабатываемые
требования структурируют по каждой из компонент информационной
системы, включая функции, процессы, данные, интерфейсы, диалоги
и т.п. средствами соответствующих моделей.
Проектирование также является фазой жизненного цикла, которая
следует за фазой анализа. Однако в противоположность фазе анализа,
которая является практически не зависящей от технологий реализации информационной системы и представляет свои решения в виде
логических моделей, фаза проектирования, наоборот, является технологически зависимой фазой и выполняется с учетом произведенного
выбора технологических сред и платформ реализации будущей информационной системы. На этой фазе проектировщики разрабатывают физические модели, выражающие конкретное понимание того, как
будет работать система. Действия в рамках проектирования не обязательно должны быть последовательны. Например, проектирование
данных, входов и выходов системы и интерфейсов являются взаимодействующими процессами, позволяющими определить недостатки и
356
недостающие элементы. Это означает, что репозиторий проекта или
CASE репозиторий становится активным и развивающимся компонентом управления разработкой системы в ходе проектирования. Результаты дизайна включают в себя физические подробные функциональные спецификации для входов системы, выходов, интерфейсов,
диалогов, и базы данных. Репозиторий CASE обновляется для включения результата проектирования каждой формы, отчета, интерфейса,
диалога, и отношения. Только тогда, когда каждый элемент дизайна
согласуется с другими, и каждый удовлетворяет конечного пользователя, тогда фаза проектирования является завершенной.
В этом учебном пособии сделана попытка комплексно рассмотреть
вопросы архитектуры, методологий и принципов разработки информационных систем, а также подробно осветить этапы разработки,
начиная от этапа стратегического планирования, через этап анализа, и
заканчивая проектированием.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Баллод Б.А., Гвоздева Т.В. Проектирование информационных
систем. Основы управления проектами. СПб. : Лань, 2020.
2. Вейцман В.М. Проектирование информационных систем.
СПб. : Лань, 2019.
3. Водяхо А.И., Выговский Л.С., Дубенецкий В.А., Цехановский В.В.
Архитектурные решения информационных систем. СПб. : Лань, 2017.
4. Грекул В.И., Коровкина НЛ. Проектирование информационных систем : учебник и практикум для академического бакалавриата.
М. : Юрайт, 2017.
5. Григорьев М.В., Григорьева И.И. Проектирование информационных систем : учебное пособие для вузов М. : Юрайт, 2019.
6.
Жданов
С.А.,
Алфимова
А.С.,
Соболева
М.Л.
Информационные системы. М. : Прометей, 2015.
7. Избачков Ю.С, Петров В.Н., Васильев А.А. Информационные
системы : учебник для вузов. – 3-е издание. СПб. : Питер, 2011.
8. Информационные системы и технологии управления :
учебник / ВЗФЭИ ; под ред. Г.А. Титоренко. 3-е изд. М : ЮНИТИ,
2011.
9. Капитан С.В. Инструментальные средства информационных
систем. М. : Солон-пресс, 2021.
10. Коваленко В.В. Проектирование информационных систем :
учебное пособие. М. : Инфра-М, 2021.
11. Косяков А., Бимер С., Сеймур С., Свит У. Системная инженерия. Принципы и практика. М. : ДМК-Пресс, 2017.
12. Кугаевских А.В. Проектирование информационных систем.
Системная и бизнес-аналитика. Новосибирск : Изд.-во НГУ, 2019.
13. Лычкина Н.Н., Фель А.В., Морозова Ю.А., Корепин В.Н.
Информационные системы управления производственной компанией :
учебник и практикум для академического бакалавриата. М. : Юрайт,
2016.
14. Меняев М.Ф., Кузьминов А.С., Планкин Д.Ю. Информационные системы управления предприятием : учебное пособие. М. :
Изд-во МГТУ им. Н.Э. Баумана, 2013.
15. Норенков И.П. Автоматизированные информационные системы. М. : Изд.-во МГТУ им. Баумана, 2011.
16. Остроух А.В., Помазанов А.В. Теория проектирования
распределенных информационных систем : монография. СПб. :
Лань, 2019.
17. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. СПб. : Лань, 2019.
18. Рочев К.В. Информационные технологии. Анализ и проектирование информационных систем : учебное пособие. СПб. : Лань,
2019.
19. Рыбников А.И. Информационные системы управления
производственной компанией. М. : Юрайт, 2020.
20. Рыбников А.И., Рыжко Н.А. Информационные системы
управления производственной компанией : учебник для академического бакалавриата. М. : Юрайт, 2019.
21. Соловьев И.В., Майоров А.А. Проектирование информационных систем. Фундаментальный курс : учебное пособие для
высшей школы. М. : Академический проект, 2009.
22. Чернопрудова Е.Н., Щелоков С.А. Проектирование распределенных информационных систем. Оренбург : Изд.-во ОГУ,
2017.
23. Чистов Д. В., Золотарюк А.В., Ничепорук Н.Б., Мельников П.П. Проектирование информационных систем : учебник и
практикум для академического бакалавриата. М. : Юрайт, 2019.
24. Avison D.E. and Fitzgerald G. Methodologies for Developing
Information Systems: A Historical Perspective // The Past and Future of
Information Systems: 1976-2006 and Beyond. IFIP 19th World Computer
Congress, TC-8, Information System Stream, August 21-23, 2006,
Santiago, Chile, Series: IFIP Advances in Information and Communication,
Vol. 214. Spriger, 2006.
25. Avison D.E. and Fitzgerald G. Where Now for Development
Methodologies // Communications of the ACM 1. 2003. № 1.
26. Avison D.E., Fitzgerald G. Information Systems Development:
Methodologies, Techniques and Tools. McGraw-Hill, Maidenhead, 2006.
27. Avison D.F., Torkzadeh G. Information Systems Project Management. London Sage Publication, 2009.
28. Dunkan J., Rackley L., Walker A. SSADAM in Practice. London:
Macmillan Press, 1995.
29. Hoffer J. A., George J. F., Valacich J.S. Modern System Analysis
and Design.London: Pearson Education, 2014.
30. Kendall К., Kendall J. E. Systems Analysis and Design. London:
Pearson Education, 2014.
31. Masoud Y., Atieh В., Hesam A.R. A Framework for Selection of
Information Systems Development Methodologies // Computer and
Information Science. URL: http://www.ccsenet.org/journal/index.php/
cis/article/view/1848/1756
32. Sowa J.F., Zahman J.A. Extending and Formalizing the
Framework for Information System Architecture // IBM System Journal
31. 1992. № 3.
33. Whitten J.L., et. all. System Analysis and Design Methods.
Boston: MacGraw-Hill, 1998.
34. William Т., et all, Information Systems Methodologies. Reading:
Addison-Wesley, 1994.
35. Zahman J.A. A Framework for Information Systems
Architecture // IBM System Journal 26. 1987. № 3.
