Разработка концепции ИС.

 

На этом этапе системный аналитик должен выполнить тщательное обследование предметной области с позиций системного подхода:

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

2. Уточнить перечень выходных документов организации.

3. Уточнить перечень входных документов организации.

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

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

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

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

При построении модели « TO BE » следует также максимально удовлетворять требованиям процессного подхода к управлению: правильно определять состав функций каждого бизнес-процесса на нижних уровнях иерархии. Выходом каждого бизнес-процесса должен воспользоваться хотя бы один клиент, необходимо максимально сократить количество подразделений, поскольку большинство проблем возникает на границах между под-разделениями организации. Для этого надо либо заранее описать действия на всех этапах бизнес-процесса, либо изменить структуру подразделений, либо изменить поток работ.

Однако основным инструментом при построении модели «TO BE» является Business process reengineering ( BPR ) - это радикальный способ реконструкции управления деятельностью предприятия. Цель BPR - добиться более гибкой реакции предприятия на изменения требований потребителей или на прогноз таких изменений при снижении затрат всех видов.

Реинжиниринг изменяет реконструируемые бизнес-процессы следую-щим образом.

1. Несколько рабочих процедур объединяются в одну. Для перепроектированных процессов характерно отсутствие технологии «конвейера», в рамках которой на каждом рабочем месте выполняются простые задания или рабочие процедуры. Теперь они интегрируются в одну – происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс. Горизонтальное сжатие ускоряет выполнение процесса примерно в десять раз.

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

3. Шаги процесса выполняются в естественном порядке. Реинжиниринг

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

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

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

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

7. Минимизируется количество согласований. Задача реинжиниринга состоит в минимизации согласований путем сокращения внешних точек контакта. Речь идет о стирании граней между функциональными подразде-лениями.

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

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

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

На основе этих положений BPR создается модель «TO BE». Рассмотрим построение модели «ТО ВЕ» на примере управления городом, используя для этого стилизованные диаграммы потоков данных «объектного» типа. На рис. 37 представлена модель управления городом «AS IS» (функциональная IDEF0-модель приведена в Приложении №2), при которой весь груз проблем по обеспечению своей жизнедеятельности (поиск поставщиков, закупка оборудования и материалов, оплата коммунальных услуг, выплата зарплаты и пр.) несут на себе бюджетные учреждения: школы, больницы, детские сады и т.п. При этом все эти действия выполняются неквалифицированными специалистами, которые не всегда правильно ориентируются в выборе поставщиков, качественного оборудования и товаров, а также возможны всевозможные финансовые нарушения и махинации.

Рис. 37. Модель управления городом «AS IS»

Модель управления «ТО ВЕ» финансовыми и материальными потока-ми муниципального образования построена по принципу корпорации, в ко-торой централизован ряд финансово-хозяйственных процедур (рис. 38). Функциональная иерархическая IDEF0-модель приведена в Приложении №3.

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

Переход на единую схему муниципальных закупок дает экономию в 15-20%, автоматизация учета расходов местного бюджета может принести до 20% экономии.

Рис. 38. Модель управления городом «TO BE»

Данный пример является типичной задачей бизнес-анализа, для которой широко применяются методологии IDEF0, IDEF3 и DFD.

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

 

Техническое задание

 

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

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

 При разработке технического задания необходимо решить следующие задачи:

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

· разработать и обосновать требования, предъявляемые к подсистемам;

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

· установить общие требования к проектируемой системе;

· определить перечень задач создания системы и исполнителей;

· определить этапы создания системы и сроки их выполнения;

· провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

ТЗ на ИС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

Эти разделы подробно описаны в ГОСТе, но особенно следует обратить внимание на следующие моменты.

В разделе «Требования к системе» в подразделе требования к функциям (задачам), выполняемым системой, следует перечислить все блоки нижнего уровня иерархии дерева узлов модели “TO BE” (Приложение №3).

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

Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию си-стемы в соответствии с ГОСТ 24.601, сроки их выполнения. В данном разделе также приводят:

1) перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

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

В разделе « Порядок контроля и приемки системы» указывают виды (приемочные испытания, опытная эксплуатация и приемочные испытания), состав, объем и методы испытаний системы на основе стандарта ГОСТ 34.603-92. Рекомендуется указать кто (разработчик или заказчик) разрабатывает программу и методики испытаний.

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

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

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

В разделе «Требования к документированию» приводят согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и ЕСКД.

В последнее время рекомендуется разрабатывать профиль стандартов [1, 2] на разрабатываемую ИС и утверждать его в составе ТЗ.

После утверждения ТЗ разработчик и заказчик заключают контракт на разработку ИС, с указанием этапов выполнения работ, сроков их выпол-нения и стоимости.

 

Технический проект

 

Этап технического проекта является самым ответственным и решающим в успешном завершении разработки ИС. Этап выполняется на основе стандарта РД 50-34.698-90.

Технический проект ИС содержит основные проектные решения по системе в целом, ее функциям и всем видам обеспечения ИС, которых должно быть достаточно для разработки программных кодов и рабочей документации. В стандарте ГОСТ 34.201-89 приведены более 20 документов, которые следует разработать на этом этапе: пояснительная записка к техническому проекту, ведомость технического проекта, перечень входных сигналов и данных, перечень выходных сигналов (документов), описание автоматизируемых функций, описание информационного обеспечения системы, описание организации информационной базы, описание комплекса технических средств и др. Содержание этих документов приведены в стандарте РД 50-34.698-90.

Для упрощения оформления документации для этапа технический проект предлагаются так называемые “Утвержденные спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты” [2]. Эти спецификации тре-бований являются основой для детального планирования процесса разработки программных средств и их компонентов. Под спецификациями требований понимается формальное описание свойств всех объектов будущего программного продукта: программных модулей, таблиц БД и элементов пользовательского интерфейса.

Поэтому в упрощенном варианте рекомендуется следующий набор до-кументов для этапа технический проект:

·пояснительная записка к техническому проекту;

· спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты;

· описание организации информационной базы.

Содержание пояснительной записки к техническому проекту подробно описано в стандарте РД 50-34.698-90 и не требует дополнительных объяснений. Она оформляется в виде отдельного документа с титульным листом, содержащим утверждающие и согласующие подписи.

Спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты содержат описание свойств трех основных компонент ИС: программные модули, таблицы БД и пользовательский интерфейс.

Спецификации для программного модуля содержат назначение и характеристика каждого программного модуля (постановка задачи, общие требования к входным и выходным данным, описание алгоритма функционирования) и результаты выполнения модуля (выходной документ, экранная форма и т.п.). В качестве программных модулей описываются все функциональные блоки нижнего уровня иерархии модели “TO BE” (см. дерево узлов в Приложении №3).

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

Спецификации для таблиц БД содержат описание каждого поля таблиц (тип и размер поля, его смысловое значение).

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

Документ «Описание организации информационной базы» содержит разделы:

· входная информация;

· выходная информация;

· логическая структура базы;

· физическая структура базы.

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

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

В разделе «Логическая структура» приводят описание состава данных, их форматов и взаимосвязей между данными (ER-диаграмма).

В разделе «Физическая структура» приводят описание избранного варианта расположения данных на базе конкретного СУБД.

На этапе технического проекта завершается проектирование и начинается разра6отка ИС с помощью программных инструментариев, предназначенных для этих целей, например с помощью Delphi, Oracle Developer / 2000 и др.

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

На этапе "Ввод в действие" выделяются три группы работ: подготов-ка персонала, пусконаладочные работы и испытания.

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

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

Испытания системы в полном объеме содержат три стадии, подробно описанные в ГОСТ 34.603-92: предварительные испытания, опытная эксплуатация и приемочные испытания. Общим для них является созда-ние комиссий для проведения испытаний, программы, методик и протоколов испытаний, а также акта об их результатах.

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

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

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

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

 

Литература

 

1. Коваленко В.В. Проектирование информационных систем. РГРТУ, Рязань, 2006. 184 с.

2. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. М.: Научная книга, 1997. 368 с.

3. Маклаков В.С. Создание информационных систем с All Fusion Modeling Suite. М.: ДИАЛОГ-МИФИ, 2003. 432 с.

 

 

 

Приложение №1

Организационная диаграмма и Swim Lane diagram

 

 

 

 

 

Приложение №2

Функциональная модель “AS IS” управления городом

 

 

 

 

 

 

Приложение №3

Функциональная модель “ТО ВЕ ” управления городом

 

 

 

 

 

Приложение №4

Пример курсового проекта “ИС продуктового магазина самообслуживания”