Системный подход разработки информационных систем

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

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

     Возможно  также существование других вариантов взаимодействия управляемой и управляющей систем.

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

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

     1.3. Цикл разработки информационных систем 

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

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

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

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

     Для этого необходимо рассмотреть такие главные вопросы:

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

     • целесообразно ли создание новой  информационной системы;

     • действительно ли ее можно будет  реализовать (создать).

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

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

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

     Этап  внедрения (ввода  в эксплуатацию) завершается  созданием работоспособной  системы. На этом этапе  выполняются такие  мероприятия:

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

     • проводится тестирование системы и  ее документирование;

     • проводится обучение персонала;

     • осуществляется переход на новую  систему.

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

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

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

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

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

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

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

     1.4. Содержание этапа "Системное проектирование"  

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

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

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

     В процессе проектирования различают  шаги: (1) логическое проектирование, (2) физическое проектирование, (3) системные спецификации.

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

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

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

     • пользовательского интерфейса (командных  линеек, панелей меню, диалоговых окон, сообщений, экранов входных и  выходных форм);

     • программного обеспечения (программ и  процедур).

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

     Проектирование  информационного обеспечения выявляет и документирует три его главные  стадии: (1) сущности, т. е. объекты; (2) связи  объектов; (3) правила интеграции сущностей  и описания их ролей.

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

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

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

     Например, если отношения "сущность-связь" описывают текстом, то это выглядит так:

     "один  к одному": "ПАЦИЕНТ < — > КОЙКА";

     "один  ко многим": "ПАЦИЕНТ « —  > ПАЛАТА;

     "многие  ко многим": "ПАЦИЕНТ «—»  ХИРУРГ".

     Правила интеграции логических элементов в  отдельные записи фиксируются в  специальной таблице  соответствия записей и их элементов. В первом столбце таблицы однократно фиксируется имя каждого  уникального типа записи (например, ПРИХОД-НА-СКЛАД), а в первой строке заголовка этой таблицы также  однократно перечислены уникальные имена элементов всех записей (НОМЕР-ДОКУМЕНТА, ДАТА-ПОЛУЧЕНИЯ, СУММА-НАЧИСЛЕНО и т. п.). На пересечении строк и столбцов таблицы ставятся символы вхождения элементов в записи. Для того, чтобы избежать неоднозначного использования элементов, в специальном словаре фиксируется точный смысл и роль каждого элемента базы данных. Словарь содержит текстовые характеристики (толкование) всех элементов с целью обеспечения однозначного понимания их смысла (прежде всего проектировщиками и пользователями, участвующими в проектировании).

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

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