Методические указания для курсового проектирования по дисциплине “ (стр. 9 из 18)
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», затем выбирают одну оптимальную, которая является основой для создания будущей ИС: она определяет состав функций системы, является основой для построения логической базы данных и пользовательского интерфейса, которые строятся на этом этапе.
6.3. Техническое задание
Полученные на предыдущем этапе функциональная модель, база данных логического уровня и пользовательский интерфейс разрабатываемой системы позволяют разработчику и заказчику определить сложность и тру-доемкость разработки ИС, ее функциональный состав, структуру информации, условия эксплуатации. Этой информации достаточно для разработки технического задания (ТЗ) на ИС (ГОСТ 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] на разрабатываемую ИС и утверждать его в составе ТЗ.
После утверждения ТЗ разработчик и заказчик заключают контракт на разработку ИС, с указанием этапов выполнения работ, сроков их выпол-нения и стоимости.
6.4. Технический проект
Этап технического проекта является самым ответственным и решающим в успешном завершении разработки ИС. Этап выполняется на основе стандарта РД 50-34.698-90.
Технический проект ИС содержит основные проектные решения по системе в целом, ее функциям и всем видам обеспечения ИС, которых должно быть достаточно для разработки программных кодов и рабочей документации. В стандарте ГОСТ 34.201-89 приведены более 20 документов, которые следует разработать на этом этапе: пояснительная записка к техническому проекту, ведомость технического проекта, перечень входных сигналов и данных, перечень выходных сигналов (документов), описание автоматизируемых функций, описание информационного обеспечения системы, описание организации информационной базы, описание комплекса технических средств и др. Содержание этих документов приведены в стандарте РД 50-34.698-90.
Для упрощения оформления документации для этапа технический проект предлагаются так называемые “Утвержденные спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты” [2]. Эти спецификации тре-бований являются основой для детального планирования процесса разработки программных средств и их компонентов. Под спецификациями требований понимается формальное описание свойств всех объектов будущего программного продукта: программных модулей, таблиц БД и элементов пользовательского интерфейса.