А. И. Сухомлинов

РАЗРАБОТКА ИНФОРМАЦИОННЫХ СИСТЕМ

Учебное пособие

ebooks@prospekt.org

Информация о книге

УДК 681.3.061

ББК 65.39

         С91

Автор: Сухомлинов А. И.

Рецензенты:

Розенбаум А. Н. — д-р техн. наук, профессор, зав. лабораторией прогнозирования состояния и надежности сложных систем ИАПУ ДВО РАН;

Рагулин П. Г. — канд. техн. наук, профессор, зав. кафедрой информационных систем в экономике ДВГУ.

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

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

УДК 681.3.061

ББК 65.39

© ДВФУ, 2008

© ООО «Проспект», обложка, 2015

© ООО «Проспект», электронная версия книги, 2015

ПРЕДИСЛОВИЕ

Бурное информационное развитие последних лет, многие технические и научные достижения в информационных системах и одновременно экспоненциальный рост применения таких систем, глобализация экономики и усиление конкуренции постоянно требуют как повышения качества разрабатываемых информационных систем, так и качества самого процесса разработки. Несмотря на более чем пятидесятилетний опыт разработки информационные системы все еще не могут удовлетворить предприятия и организации не только размером связанных с ними инвестиций, но и результативностью вводимых в эксплуатацию систем. При этом в некоторых странах 53% от общего количества разрабатываемых проектов информационных систем терпят неудачу, превышение фактических затрат разработки проектов над планируемыми в среднем составляет 89%, а инвестиции в системы – 40% от всех капитальных вложений.

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

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

Глава 1.
АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ

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

1.1. Введение в архитектуру информационных систем

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

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

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

Рассмотренное предположение, что осмысление архитектуры информационных систем является важным для разработки строгого подхода, естественно вызывает вопрос: «Что на самом деле является архитектурой информационных систем?» К сожалению, среди сторонников архитектуры информационных систем настолько мало согласованности в концепциях или в спецификациях «архитектуры», что термин «архитектура информационных систем» теряет свой смысл. Более того, представляется, вероятно, необоснованным само ожидание такого согласия или общности в определении от профессионального сообщества по обработке данных. Эмоциональная приверженность, связанная с устоявшимися интересами различных школ, требует нейтрального, беспристрастного, независимого источника в качестве необходимого условия для любой приемлемой работы в этой области.

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

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

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

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

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

1.2. Представления как человеческий фактор информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3. Инфраструктура архитектуры информационных систем

Применительно к информационной системе слово «архитектура» является метафорой, которая может применяться наравне как к конструкции компьютерной системы, так и к конструкции дома. Инфраструктура архитектуры информационной системы представляет собой развитие этой метафоры. Инфраструктура уподобает представления, используемые для описания информационной системы, представлениям, порождаемым архитектором при проектировании и строительстве дома.

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

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

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

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

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

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

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

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

Рис. 1.1. Первоначальная инфраструктура архитектуры информационных систем

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

Таблица 1.1

Характеристики строки инфраструктуры

Строка | Представление | Ограничения | Модель
1 | Планировщик | Финансовые/внешние | Намерение
2 | Владелец | Использование/стратегия | Модель предприятия
3 | Дизайнер | Структура/операции | Модель системы
4 | Изготовитель | Технология | Технологическая модель
5 | Субподрядчик | Внедрение | Внеконтекстные модели

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

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

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

Несмотря на то, что первоначальная инфраструктура предлагала ограничения моделирования для каждой из 15 ячеек, она не включала языка формальной спецификации, пригодного для детального дизайна системы или для заполнения репозитория в цикле разработки приложений (Application Development cycle, AD/Cycle) или в других средствах автоматизированного конструирования программ (Computer-Aided Software Engineering, CASE). Единственным средством для формальной спецификации, явно указанным в описании инфраструктуры, является язык E–R диаграмм.

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

1.4. Расширенная инфраструктура архитектуры

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

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

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

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

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

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

Рис. 1.2. Пример организационной схемы

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

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

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

Соединительное звено «работа», возможно, должно интерпретироваться как результат работы, чтобы избежать путаницы с концепцией процесса или функции, которая рассматривается в столбце «процесс». В дальнейшем оно могло бы обозначать своего рода представление материалов пользователем или вход/выход процесса. Чтобы избежать какой-либо путаницы между концепциями результата работы столбца «люди» и входом/выходом столбца «процесс» было бы полезным изменить первоначальное название соединительного звена в столбце «процесс» с «вход/выход» на «аргумент», который является математическим термином для входа функции, являющейся средством преобразования, как, например, в выражении f(х) = К, где f является преобразованием, х – входным аргументом и К – выходом.

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

Таблица 1.2

Содержание ячеек в столбце люди (кто)

Строка | Представление | Пример ячейки | Агент | Работа
1 | Планировщик | Список организаций/подразделений | Класс агента |
2 | Владелец | Организационная структура | Подразделение организации | Результат деятельности
3 | Дизайнер | Архитектура интерфейса персонала | Роль | Единица работы
4 | Изготовитель | Человеко-машинный интерфейс | Пользователь | Задание
5 | Субподрядчик | Архитектура безопасности | Лицо | Транзакция

Столбец время (когда). Эта абстракция реального мира предназначена для конструирования отношений типа «событие-событие» для того чтобы установить критерий производительности и количественные уровни для ресурсов предприятий.

Рис. 1.3. Пример графика модели времени

Например, между «событием 1», заключающимся в анонсировании продукта в момент времени t₀, и «событием 2», состоящим в отправке продукта первому клиенту, в момент времени t₁, находится промежуток времени (цикл, период времени) (t₁ – t₀). Длина этого промежутка устанавливает внешние обязательства предприятия, также как и уровень ресурсов, требуемых для выполнения этих обязательств. Вообще, чем короче время цикла, тем больше требуется ресурсов для выполнения обязательств, и наоборот – чем оно длиннее, тем меньше необходимо требуемых ресурсов для этой цели.

На рис 1.3 представлен пример графического представления, которое демонстрирует характеристики времени предприятия. Здесь вертикальная ось соответствует управлению, а горизонтальная ось представляет время. Точки или моменты времени изображены окружностями, а продолжительность обозначена в виде цикла периодического процесса. В табл. 1.3 приводится список видов информации, которые соответствуют ячейкам столбца «когда».

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

Таблица 1.3

Содержание ячеек в столбце время (когда)

Строка | Представление | Пример ячейки | Событие | Цикл
1 | Планировщик | Список событий | Основное событие | Основной цикл
2 | Владелец | Основной график | Бизнес событие | Бизнес-цикл
3 | Дизайнер | Структура обработки | Системное событие | Цикл обработки
4 | Изготовитель | Архитектура управления | Выполнить | Цикл компонента
5 | Субподрядчик | Временное определение | Прервать | Машинный цикл

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

Содержание ячеек в столбце мотивации, как это следует из правил инфраструктуры, соответствует мотивации «цели-средства-цели», рассматриваемой в табл. 1.4.

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

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

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

Рис. 1.4. Пример модели «цели-средства-цели»

Таблица 1.4

Содержание ячеек в столбце мотивация

Строка | Представление | Пример ячейки | Цель | Средство
1 | Планировщик | Список целей | Основная цель | Основные стратегии
2 | Владелец | Бизнес-план | Бизнес-цели | Бизнес-стратегия
3 | Дизайнер | Архитектура знаний | Критерий | Альтернатива
4 | Изготовитель | Дизайн знаний | Условие | Действие
5 | Субподрядчик | Определение знаний | Подусловие | Шаг

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

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

1.5. Правила инфраструктуры

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

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

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

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

Таблица 1.5

Пример компании в шестиколоночной инфраструктуре

ЧТО?
ОБЪЕКТ/
ОТНОШЕНИЕ
КАК?
ФУНКЦИЯ/
АРГУМЕНТ
ГДЕ?
УЗЕЛ/
СВЯЗЬ
КТО?
АГЕНТ/РАБОТА
КОГДА?
ВРЕМЯ/ЦИКЛ
ПОЧЕМУ?
ЦЕЛИ/
СРЕДСТВА

НАМЕРЕНИЕ
ПЛАНИРОВЩИК
КОМПАНИЯ, АВТОМОБИЛИ, ПЛАТА, ЛИЦЕЗИИ, ИСТОРИИ АВТОМОБИЛЕЙ
РЕГИСТРИРОВАТЬ, ПЕРЕДАВАТЬ, ПОЛУЧАТЬ, ОБЯЗЫВАТЬ
ЭМЕРАЛД, КАНЗВС, ГОЛИВУД, ФЛИНТ
ДИРЕКТОР, МЕНЕДЖЕР, КЛЕК, СОБСТВЕННИКИ АВТОМОБИЛЕЙ
ВРЕМЯ ПРОДАЖИ, РЕГИСТРАЦИИ ПЕРЕДАЧИ, ЛИКВИДАЦИИ
РЕГУЛИРОВАТЬ ПРОДАЖИ, ЗАНИМАТЬ ДЕНЬГИ, РАЗЫСКИВАТЬ АВТОМОБИЛИ

МОДЕЛЬ ПРЕДПРИЯТИЯ
ВЛАДЕЛЕЦ
КАЖДЫЙ АВТОМОБИЛЬ ПРЕДСТАВЛЯЕТ КОНКРЕТНУЮ МОДЕЛЬ
СОБСТВЕННОСТЬ ПЕРЕДАЕТСЯ РЕГИСРАЦИЕЙ ПЕРЕДАЧИ
РЕГИСТРАЦИИ ФИКСИРУЮТСЯ В ОФИСАХ КОМПАНИИ
КЛЕРК ДОЛЖЕН ЗАФИКСИРОВАТЬ КАЖДУЮ РЕГИСТРАЦИЮ
КОГДА АВТОМОБИЛЬ БЫЛ ВЫПУЩЕН, ПЕРЕДАН, УНИЧТОЖЕН
ВЕСТИ ТОЧНЫЙ УЧЕТ И ВЗЫМАТЬ ПЛАТУ

МОДЕЛЬ СИСТЕМЫ
ДИЗАЙНЕР
ФУНКЦИОНАЛЬНАЯ ЗАВИСИМОСТЬ МОДЕЛИ ОТ АВТОМОБИЛЯ
ИСТОРИЯ АВТОМОБИЛЯ ОБНОВЛЯЕТСЯ МОДУЛЕМ ПЕРЕДАЧИ
КАЖДЫЙ ОФИС ДОЛЖЕН ИМЕТЬ СВЯЗЬ СО ШТАБ-КВАРТИРОЙ КОМПАНИИ
КЛЕРК ДОЛЖЕН ВВЕСТИ ИНФОРМАЦИЮ С ТЕРМИНАЛА
ОБНОВЛЕНИЯ БАЗЫ ДАННЫХ ПРОИСХОДЯТ ЧЕРЕЗ НЕРАВНОМЕРНЫЕ ИНТЕРВАЛЛЫ
СТАРАЯ СИСТЕМА ПАКЕТНОЙ ОБРАБОТКИ РАБОТАЕТ НЕДОСТАТОЧНО БЫСТРО

ТЕХНОЛОГИЧЕСКАЯ МОДЕЛЬ
ИЗГОТОВИТЕЛЬ
ОТНОШЕНИЕ АВТОМОБИЛЬ СОДЕРЖИТ СТОЛБЕЦ ДЛЯ ИДЕНТИФИКАТОРА МОДЕЛИ
ПЕРЕДАЧА ВЫПОЛНЯЕТСЯ COBOL ПРОГРАММОЙ XFR397A
ЗАПИСИ ОТДЕЛЕНИЙ ФИРМЫ ДУБЛИРУЮТСЯ В ШТАБ-КВАРТИРЕ
КЛЕРК ЗАПОЛНЯЕТ БЛАНК КЕ0972, ЧТОБЫ НАЧАТЬ РЕГИСТРАЦИЮ
КАЖДЫЙ МОДУЛЬ ВЫЗЫВАЕТСЯ ВЫБОРОМ ИЗ МЕНЮ
ЭФФЕКТИВНОЕ, НАДЕЖНОЕ ОБСЛУЖИВАНИЕ В ПРЕДЕЛАХ БЮДЖЕТА

КОМПОНЕНТЫ
СУБПОДРЯДЧИК
МОDELID РІС Х(15)
SELECT SNO FROM HIST WHERE...
INSTALL ТСР/IР LINK ТО OZNET
УСТАНОВИТЬ ОГРАНИЧИТЕЛИ ДЛЯ НАПРАВЛЕНИЯ ОЧЕРЕДИ К КЛЕРКУ
ИСПОЛЬЗОВАТЬ ВСПЛЫВАЮЩЕЕ ОКНО, ВЫБРАННОЕ МЫШЬЮ
УДОВЛЕТВОРЯТЬ СПЕЦИФИКАЦИЯМ КАЖДОГО МОДУЛЯ

РАБОТАЮЩАЯ СИСТЕМА
ДАННЫЕ
ФУНКЦИЯ
СЕТЬ
ОРГАНИЗАЦИЯ
ГРАФИК
СТРАТЕГИЯ

Рис. 1.5. Шестиколоночная инфраструктура архитектуры информационных систем

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

Базовая модель для каждого столбца фактически является базовой метамоделью. Она является базовой потому что она одинаково применима для каждой ячейки в столбце. Она также «мета» потому, что является моделью модели предприятия. Например, модель предприятия в ячейке А2 могла бы представлять ряд работников, имеющих отношение к организации, имеющей отношение к заказчикам, имеющих отношение к продукции. Метамодель этой модели – это абстракция «объект-отношение-объект». Подобным образом каждый столбец имеет простую базовую модель, которая составляет общую метамодель для этого столбца. В табл. 1.6 представлены примеры для столбцов А, В и С.

Таблица 1.6

Компоненты для базовых метамоделей столбцов А, В, и С.

Элементы метамодели
Столбец А
Данные (что)
Столбец В
Функции (как)
Столбец С
Сеть (где)

Базовый объект
Объект
Функция
Узел

Соединяющее звено
Отношение
Аргумент
Связь

Правило 3. Базовая модель для каждого столбца должна быть уникальной. Свойство уникальности является существенным для каждой классификационной схемы. Следовательно, ни один объект и ни одно соединительное звено в базовой колоночной модели не повторяется ни в имени, ни в понятии. На пример, объект и отношение являются уникальными в столбце А. Функция и аргумент уникальны в столбце В. Объект не является эквивалентным функции, а отношение не эквивалентно аргументу. Они могут быть связаны друг с другом, т.к. они все являются абстракциями одного и того же реального предприятия. Эта логика применима ко всем базовым колоночным моделям, что подтверждает уникальность базовых моделей.

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

• Владелец: имеет дело с эксплуатационными ограничениями, обоими эстетическими и практичности в концептуальном представлении конечного продукта.

• Дизайнер: имеет дело с ограничениями дизайна – законами физики или природы в логическом представлении конечного продукта.

• Изготовитель: имеет дело с ограничениями конструкции – современным состоянием методов и технологий в физическом представлении конечного продукта.

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

Таблица 1.7

Изменения смысла объектов от строки к строке в столбце А

Строка | Представление | Базовый объект
2 | Владелец | Бизнес-объект (вещь реального мира)
3 | Дизайнер | Объект данных (логическое представление)
4 | Изготовитель | Технический объект (физическое представление)

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

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

• Бизнес-объект может встречаться только в ячейке А2.

• Объект данных может встречаться только в ячейке А3.

• Бизнес-процесс может встречаться только в ячейке В2.

• Прикладная функция может встречаться только в ячейке В3.

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

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

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

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

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

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

Ключевые термины

Архитектура информационных систем | Модель сети
Базовая модель столбца | Модель процессов
Владельцы системы | Модель цели-средства-цели
Дизайнеры систем | Организационная схема
Изготовители систем | Пользователи системы
Информационные работники | Представление архитектуры
Модель времени | Системный аналитик
Модель данных | Технологическая модель
Модель предприятия | Функциональная модель

Контрольные вопросы

1. Назовите шесть аспектов рассмотрения информационной системы.

2. Назовите пять уровней представления инфраструктуры архитектуры информационных систем.

3. Назовите пять категорий лиц, заинтересованных в информационной системе организации.

4. Дайте определение архитектуры информационных систем.

5. Определите, к каким ячейкам инфраструктуры архитектуры информационных систем относятся методы моделирования DFD, IDEF0, IDEF1X?

6. Назовите шесть правил инфраструктуры архитектуры систем.

7. Дайте определение базовой метамодели инфраструктуры.

8. В чем заключается уникальность каждой ячейки инфраструктуры?

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

10. Что символизирует каждая строка инфраструктуры?

11. Каким свойством обладает базовая модель для каждого столбца инфраструктуры архитектуры информационных систем?

12. Что определяют совместно все модели одной строки инфраструктуры?

13. Что определяют модели всех ячеек столбца инфраструктуры

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

15. В чем состоит свойство аддитивности применительно к строкам инфраструктуры архитектуры информационных систем?

16. Приведите примеры моделей для ячеек инфраструктуры.

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

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

Глава 2.
ЖИЗНЕННЫЙ ЦИКЛ И МЕТОДОЛОГИИ РАЗРАБОТКИ СИСТЕМ

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

2.1. Традиционная разработка систем

Разработка систем

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

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

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

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

Область разработки информационных систем

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

Методологии

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