<<
>>

Классическое проектирование информационных систем

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

Методы проектирования таких ИС в 80-х годах были хорошо описаны и в зарубежной, и в отечественной литературе разных направлений: методические монографии, стандарты (ГОСТы, ANSI, ISO), учебники.

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

ванной системы, задание на выполнение работ (proposal for the development, agreement, mobilization); обследование: предпроектное обследование, общий анализ ситуации на предприятии, разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning, requirement definition); концепция, ТЗ исследования требований предприятия и пользователей, выработка рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и частных ТЗ по подсистемам (strategy planning, analysis, requirement specification, function description); эскизный проект: разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design); опытный вариант ИС: разработка упрощенного варианта, пилотного проекта будущей ИС (pilot-project, test development); опытное использование пилот-проекта ИС, разработка исправлений и дополнений к ТЗ (test, corrected requirement specification); 777: разработка технического проекта ИС (detailed analysis and design, test development); РП: разработка рабочей документации проекта (development, test, system implementation); ввод в действие: по-другому — «внедрение» ИС (deployment, put into operation).

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

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

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

Таблица 5.2 Структура формирования информационной системы

Стадии

проекта

Виды обеспечения информационной системы

организа

ционное

методи

ческое

инфор

маци

онное

програм

мное

аппарат

ное

Запуск

+-

Обследование

+-

+-

+-

Концепция ТЗ

+-

+-

+-

Эскизный

проект

+-

+-

+-

+-

ТП

+-

++

+

+-

+-

РП

++

++

++

++

+

Ввод

в действие

++

++

++

++

++

Символами «+», «н—» и «++» показаны примерные оценки доли наличия каждого компнента на каждой стадии

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

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

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

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

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

См. об этом также в [45]:

Анализ должен подвести руководство к вопросу о том, как надо изменить организацию...

и далее:

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

В отечественной практике возник афоризм, описывающий эффект работы типичной АСУ, механически перемалывающей существующий бумажный поток: «Что на входе, то и на выходе». Ниже укажем, что современные аналитики до сих пор указывают на существование этого эффекта.

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

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

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

Более развитые организационные подходы. Они развивались, в первую очередь, хотя и не только, для уменьшения первого недо- стс. ка: «опозданий». Схема непрерывной разработки. Примером может служить подход, который руководители больших проектов IBM в 70-х — 80-х годах прошлого столетия называли «Продолжающейся разработкой». Характеризующей особенностью такого подхода стал непрерывный процесс разработки и развития большой ИС с планируемыми точками передачи в эксплуатацию новых версий и новых функциональных блоков (подсистем, задач) и встроенными в процесс постоянно осуществляемыми процедурами экспертизы качества, работоспособности и др.

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

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

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

действие              Использование


?!(разрав в

управлении)              X*              Сопровождение

р д Ввод в              Продолжение Ввод в              Продолжение

р действие разработки              действие              разработки

              -Ч"'"

Рис. 5.1. Схема непрерывной разработки^^Использование

Рис. 5.1. Схема непрерывной разработки

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

2. Схема циклической разработки. В 80-х годах использование принципа продолженной разработки для ускоренного поочередного внедрения отдельных программных комплексов — прикладных или общесистемных — стало развиваться в разных направлениях и получило несколько ходовых жаргонных названий, например «быстрое прототипирование» (rapid prototyping approach или fast-track). В проектный цикл для этого дополнительно включались такие стадии: разработка макета-прототипа фрагмента будущей ИС (rapid prototyping) совместно с будущим пользователем; опробование макета-прототипа фрагмента будущей ИС, доработка прототипа до работающего фрагмента ИС (feedback, improved prototype design and development).

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

Недостаток 3 и 4 (жесткость и закрытость). Рассмотренные усовершенствованные схемы проектирования претендовали и сей

час часто претендуют на получение и ввод в действие компонентов формально целостной в традиционном смысле ИС и последующей их стыковки в такую ИС.

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

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

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

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

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

Одно из популярных в то время представлений архитектуры такой закрытой ИС показано на рис. 5.2, где: компьютер конкретного типа (конкретной фирмы-производителя); конкретная операционная система для данного типа компьютера;

СУБД для 1 и 2; прикладные программы для 2 и 3: пакетные (диалоговые) для фиксированных функций или языки нерегламентированных запросов; пользователь-оператор, обученный именно для 2, 3 и 4; конечный пользователь: обучен и снабжен инструкциями для работы именно с 4 и 5.

Рис. 5.2. Модель-луковица закрытой ИС

Рис. 5.2. Модель-луковица закрытой ИС

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

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

Классические методы проектирования. Конец 70-х — начало 80-х годов — это время становления технологии интегрированных баз данных как одной из головных технологий в проектировании ИС. Был разработан и вошел в практику большой набор теоретически обоснованных методов: проектирование концептуальных и логических схем БД, организация физической среды хранения данных, планирование путей доступа к данным и др. Развивались методы проектирования функций: от методов формальной спецификации функций до структурного программирования и первых непроцедурных языков программирования четвертого поколения (4GL). Анализ функций (задач) предприятия также служил основой и в проектировании БД. Появились CASE- системы, ориентированные на формализацию информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной разработки больших программных комплексов.

В конце 70-х — середине 80-х годов XX в. и в нашей стране большое количество разработчиков успешно применяли методы разработки ИС и БД не только на интуитивно-ремесленном уровне, но и как элементы сложившейся дисциплины. Укажем на наиболее популярные из них, применявшиеся на первых стадиях проектирования.

Обследование, общий анализ ситуации на предприятии и разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning):

общий системный и ситуационный анализ текущего состояния и целей предприятия, его масштабов, возможности, стоимости и способов разработки ИС, решающей задачи, способствующие достижению целей предприятия; использование методов [45], структурного анализа [53], ГОСТов на разработку АСУ и САПР.

«Концепция, ТЗ»: исследования требований предприятия и пользователей, выработка вариантов и рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy stady, analysis, requirement specification):

анализ критических факторов успеха и риска с использованием системного и ситуационного анализа; обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др. (большое количество методик: от SADT Д. Росса до ГОСТа по предпроектным исследованиям при разработке САПР); определение соответствия существующей оргструктуры, функций, документов и других целям предприятия; проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии функций («задач»), видов документов и правил документооборота, вычленение предметных БД, определение взаимосвязей между ними; разработка предложений по изменениям на предприятии, затрагивающим оргструктуру, документооборот и др.; построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана, модификаций ER-модели П. Чена, функциональных моделей по стандартам IDEF0, по методике HIPO или др.); сбор и описание детальных требований к составу данных и алгоритмам реализации функций (см., например, популярную [16], а также [58], [61] и требования серий ГОСТ24 и ГОСТ36).

«Эскизный проект»: разработка архитектуры будущей И С в рамках эскизного проекта (detailed analysis, high level design): построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса — Кодда, четвертых и пятых нормальных форм, использование предложений комитета CODASYL); определение принципов организации в ИС интерфейсов конечного пользователя (принципы эргономики, как, впрочем, и влияние компьютерной моды, переход от командного интерфейса к диалоговым режимам «вопрос — ответ», «управление через меню»); определение модульной иерархии (верхние уровни) программного обеспечения ИС (модульное программирование, метод HIPO); определение принципов организации аппаратного компьютерного комплекса, на базе которого должна функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций доступа к данным, целых функций и режимов в целом, организации компьютерных сетей, см. также [58]);

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

Существовал набор методов, применявшихся и на других этапах.

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

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

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

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

  

<< | >>
Источник: Гринберг А.С., Король И.А.. Информационный менеджмент. 2003

Еще по теме Классическое проектирование информационных систем:

  1. Комплекс средств проектирования и развития информационных систем для информационного менеджмента
  2. Технологии проектирования информационных систем
  3. Глава 7 НОВОЕ СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
  4. Глава 5 ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
  5. Инструментальные средства проектирования и разработки информационных систем
  6. CASE-технологии проектирования автоматизированных информационных систем
  7. Часть 3. Информационные технологии в инвестиционном проектировании Раздел 13. ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ (ИС&Т) В ИНВЕСТИЦИОННОЙ ДЕЯТЕЛЬНОСТИ (ИД)
  8. Информационные технологии финансовой системы Автоматизированная информационная система «Финансы»
  9. Глава 3 ПРОФИЛИ ИНФОРМАЦИОННЫХ СИСТЕМ ДЛЯ ИНФОРМАЦИОННОГО МЕНЕДЖМЕНТА
  10. Проектирование системы цепочки ценности
  11. ИНФОРМАЦИОННЫЕ СИСТЕМЫ В ИНФОРМАЦИОННОМ МЕНЕДЖМЕНТЕ
  12. Глава 4.1. Проектирование системы управления
  13. ПЛАНИРОВАНИЕ ЦЕЛЕЙ II: ПРОЕКТИРОВАНИЕ СИСТЕМ УПРАВЛЕНИЯ
  14. Принципы проектирования оптимальных систем мотивации труда
  15. Методика проектирования логистической системы управления запасами
- Антикризисное управление - Деловая коммуникация - Документоведение и делопроизводство - Инвестиционный менеджмент - Инновационный менеджмент - Информационный менеджмент - Исследование систем управления - История менеджмента - Корпоративное управление - Лидерство - Маркетинг в отраслях - Маркетинг, реклама, PR - Маркетинговые исследования - Менеджмент организаций - Менеджмент персонала - Менеджмент-консалтинг - Моделирование бизнес-процессов - Моделирование бизнес-процессов - Организационное поведение - Основы менеджмента - Поведение потребителей - Производственный менеджмент - Риск-менеджмент - Самосовершенствование - Сбалансированная система показателей - Сравнительный менеджмент - Стратегический маркетинг - Стратегическое управление - Тайм-менеджмент - Теория организации - Теория управления - Управление качеством - Управление конкурентоспособностью - Управление продажами - Управление проектами - Управленческие решения - Финансовый менеджмент - ЭКОНОМИКА ДЛЯ МЕНЕДЖЕРОВ -