Лекции по предмету проектирование асоиу
 Скачать 0.94 Mb.
|
|
ЭТАПЫ ПРОЕКТИРОВАНИЯ. МОДЕЛЬ «AS-IS». МОДЕЛЬ «TO-BE» Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90. В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей. Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ: 1. Формирование требований к ИС. На начальной стадии проектирования выделяют следующие этапы работ: 1.1. обследование объекта и обоснование необходимости создания ИС; 1.2. формирование требований пользователей к ИС; 1.3. оформление отчета о выполненной работе и тактико-технического задания на разработку. 2. Разработка концепции ИС: 2.1. изучение объекта автоматизации; 2.2. проведение необходимых научно-исследовательских работ; 2.3. разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей; 2.4. оформление отчета и утверждение концепции. 3. Техническое задание: 3.1. разработка и утверждение технического задания на создание ИС. 4. Эскизный проект: 18 4.1. разработка предварительных проектных решений по системе и ее частям; 4.2. разработка эскизной документации на ИС и ее части. 5. Технический проект. 5.1. разработка проектных решений по системе и ее частям; 5.2. разработка документации на ИС и ее части; 5.3. разработка и оформление документации на поставку комплектующих изделий; 5.4. разработка заданий на проектирование в смежных частях проекта. 6. Рабочая документация. 6.1. разработка рабочей документации на ИС и ее части; 6.2. разработка и адаптация программ. 7. Ввод в действие: 7.1. подготовка объекта автоматизации; 7.2. подготовка персонала; 7.3. комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); 7.4. строительно-монтажные работы; 7.5. пусконаладочные работы; 7.6. проведение предварительных испытаний; 7.7. проведение опытной эксплуатации; 7.8. проведение приемочных испытаний. 8. Сопровождение ИС: 8.1. выполнение работ в соответствии с гарантийными обязательствами; 8.2. послегарантийное обслуживание. Oбследование – это изучение и диагно стиче ский ана лиз организационной структуры предприятия, его деятельности и существующей системы обработки информации. В рамках обследования осуществляется: • предварительное выявление требований, предъявляемых к будущей системе; 19 • определение оргштатной и топологической структур предприятия; • определение перечня целевых задач предприятия; • анализ распределения функций по подразделениям и сотрудникам; • определение перечня применяемых на предприятии средств автоматизации. При этом выявляются функциональные деятельности каждого из подразделений предприятия и функциональные взаимодействия между ними, информационные потоки внутри подразделений и между ними, внешние по отношению к предприятию объекты и внешние информационные взаимодействия. В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат: • данные по оргштатной структуре предприятия; • информация о принятых технологиях деятельности; • стратегические цели и перспективы развития; • результаты интервьюирования сотрудников (от руководителей до исполните- лей нижнего звена); • предложения сотрудников по усовершенствованию бизнес-процессов предприятия; • нормативно-справочная документация; • опыт системных аналитиков в части наличия типовых решений. Модели деятельности организации создаются в двух видах: • модель «как есть» («as-is») – отражает существующие в организации бизнес- процессы, описывает положение дел на предприятии (оргштатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования; позволяет понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации; • модель «как должно быть» («to-be») – интегрирует перспективные предложения руководства и сотрудников предприятия, экспертов и системных 20 аналитиков и позволяет сформировать видение новых рациональных технологий работы предприятия. Каждая из моделей включает в себя полную структурную функциональную модель деятельности, информационную модель, а также, в случае необходимости, событийную (описывающую поведение) модель. Переход от модели «как есть» к модели «как должно быть» осуществляется двумя способами: 1. Совершенствование технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников («легкий» реинжиниринг). 2. Радикальное изменение технологий и переосмысление бизнес-процессов («жесткий» реинжиниринг). Например, вместо попыток улучшения бизнес- процесса проверки кредитоспособности клиента, может быть следует задуматься, а нужна ли вообще такая проверка? Возможно затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести компания в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы закупок незначительны). 21 9 СОСТАВ И СОДЕРЖАНИЕ ТЗ Результаты обследования представляют объективную основу для формирования технического задания на информационную систему. Техническое задание – это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. При разработке технического задания необходимо решить следующие задачи: • установить общую цель создания ИС, определить состав подсистем и функциональных задач; • разработать и обосновать требования, предъявляемые к подсистемам; • разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу техничес- ких средств (включая средства связи и передачи данных); • установить общие требования к проектируемой системе; • определить перечень задач создания системы и исполнителей; • определить этапы создания системы и сроки их выполнения; • провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения. Типовые требования к составу и содержанию технического задания: 1. Общие сведения: 1.1. полное наименование системы и ее условное обозначение; 1.2. шифр темы или шифр (номер) договора; 1.3. наименование предприятий разработчика и заказчика системы, их реквизиты; 1.4. перечень документов, на основании которых создается ИС; 1.5. плановые сроки начала и окончания работ; 1.6. сведения об источниках и порядке финансирования работ; 1.7. порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств. 22 2. Назначение и цели создания (развития) системы: 2.1. вид автоматизируемой деятельности; 2.2. перечень объектов, на которых предполагается использование системы; 2.3. наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС. 3. Характеристика объектов автоматизации: 3.1. краткие сведения об объекте автоматизации; 3.2. сведения об условиях эксплуатации и характеристиках окружающей среды. 4. Требования к системе: 4.1. Требования к системе в целом: 4.1.1. требования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централиза- ции, способы информационного обмена, режимы функциони- рования, взаимодействие со смежными системами, перспекти- вы развития системы); 4.1.2. требования к персоналу (численность пользователей, квалифи- кация, режим работы, порядок подготовки); 4.1.3. показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров); 4.1.4. требования к надежности, безопасности, эргономике, транспор- табельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации. 4.2. Требования к функциям (по подсистемам): 4.2.1. перечень подлежащих автоматизации задач; 4.2.2. временной регламент реализации каждой функции; 23 4.2.3. требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точности, достоверности выдачи результатов; 4.2.4. перечень и критерии отказов. 4.3. Требования к видам обеспечения: 4.3.1. математическому (состав и область применения мат. моделей и методов, типовых и разрабатываемых алгоритмов); 4.3.2. информационному (состав, структура и организация данных, обмен данными между компонентами системы, информацион- ная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам); 4.3.3. лингвистическому (языки программирования, языки взаимо- действия пользователей с системой, системы кодирования, языки ввода-вывода); 4.3.4. программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ); 4.3.5. техническому; 4.3.6. метрологическому; 4.3.7. организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала); 4.3.8. методическому (состав нормативно-технической документа- ции). 5. Состав и содержание работ по созданию системы: 5.1. перечень стадий и этапов работ; 5.2. сроки исполнения; 5.3. состав организаций – исполнителей работ; 5.4. вид и порядок экспертизы технической документации; 5.5. программа обеспечения надежности; 24 5.6. программа метрологического обеспечения. 6. Порядок контроля и приемки системы: 6.1. виды, состав, объем и методы испытаний системы; 6.2. общие требования к приемке работ по стадиям; 6.3. статус приемной комиссии. 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие: 7.1. преобразование входной информации к машиночитаемому виду; 7.2. изменения в объекте автоматизации; 7.3. сроки и порядок комплектования и обучения персонала. 8. Требования к документированию: 8.1. перечень подлежащих разработке документов; 8.2. перечень документов на машинных носителях. 9. Источники разработки: 9.1. документы и информационные материалы, на основании которых разрабатывается ТЗ и система. 25 10 ПОНЯТИЕ ТЕХНИЧЕСКОГО ПРОЕКТА. СОСТАВ ТЕХНИЧЕСКОГО ПРОЕКТА На основе технического задания и эскизного проекта разрабатывается технический проект ИС. Технический проект системы – это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности АСУ и перечень мероприятий по подготовке объекта к внедрению. На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы. Состав и содержание технического проекта: 1. Пояснительная записка: 1.1. основания для разработки системы; 1.2. перечень организаций разработчиков; 1.3. краткая характеристика объекта с указанием основных технико- экономических показателей его функционирования и связей с другими объектами; 1.4. краткие сведения об основных проектных решениях по функциональ- ной и обеспечивающим частям системы. 2. Функциональная и организационная структура системы: 2.1. обоснование выделяемых подсистем, их перечень и назначение; 2.2. перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания; 2.3. схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы; 3. Постановка задач и алгоритмы решения: 3.1. организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими 26 задачами, характер использования результатов решения, в которых они используются); 3.2. экономико-математическая модель задачи (структурная и развернутая форма представления); 3.3. входная оперативная информация (характеристика показателей, диапазон изменения, формы представления); 3.4. нормативно-справочная информация (НСИ) (содержание и формы представления); 3.5. информация, хранимая для связи с другими задачами; 3.6. информация, накапливаемая для последующих решений данной задачи; 3.7. информация по внесению изменений (система внесения изменений и перечень информации, подвергающейся изменениям); 3.8. алгоритм решения задачи (последовательность этапов расчета, схема, расчетные формулы); 3.9. контрольный пример (набор заполненных данными форм входных документов, условные документы с накапливаемой и хранимой информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с разработанным алгоритмом расчета). 4. Организация информационной базы: 4.1. источники поступления информации и способы ее передачи; 4.2. совокупность показателей, используемых в системе; 4.3. состав документов, сроки и периодичность их поступления; 4.4. основные проектные решения по организации фонда НСИ; 4.5. состав НСИ, включая перечень реквизитов, их определение, диапазон изменения и перечень документов НСИ; 4.6. перечень массивов НСИ, их объем, порядок и частота корректировки; 4.7. структура фонда НСИ с описанием связи между его элементами; требования к технологии создания и ведения фонда; 4.8. методы хранения, поиска, внесения изменений и контроля; 27 4.9. определение объемов и потоков информации НСИ; 4.10. контрольный пример по внесению изменений в НСИ; 4.11. предложения по унификации документации. 5. Альбом форм документов. 6. Система математического обеспечения: 6.1. обоснование структуры математического обеспечения; 6.2. обоснование выбора системы программирования; 6.3. перечень стандартных программ; 7. Принцип построения комплекса технических средств: 7.1. описание и обоснование схемы технологического процесса обработки данных; 7.2. обоснование и выбор структуры комплекса технических средств и его функциональных групп; 7.3. обоснование требований к разработке нестандартного оборудования; 7.4. комплекс мероприятий по обеспечению надежности функционирова- ния технических средств. 8. Расчет экономической эффективности системы: 8.1. сводная смета затрат, связанных с эксплуатацией систем; 8.2. расчет годовой экономической эффективности, источниками которой являются оптимизация производственной структуры хозяйства, снижение себестоимости продукции за счет рационального использо- вания производственных ресурсов и уменьшения потерь, улучшения принимаемых управленческих решений. 9. Мероприятия по подготовке объекта к внедрению системы: 9.1. перечень организационных мероприятий по совершенствованию бизнес-процессов; 9.2. перечень работ по внедрению системы, которые необходимо выполнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц. 10. Ведомость документов. 28 11 ТИПОВОЕ ПРОЕКТИРОВАНИЕ ИС. ТИПОВЫЕ ПРОЕКТНЫЕ РЕШЕНИЯ (ТПР). ПАРАМЕТРИЧЕСКИ- ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ. МОДЕЛЬНО- ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия. Типовое проектное решение (ТПР) – это тиражируемое (пригодное к многократному использованию) проектное решение. Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР: • элементные ТПР – библиотеки методо-ориентированных программ – типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному); • подсистемные ТПР – пакеты прикладных программ – в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей; • объектные ТПР – отраслевые проекты ИС – типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС. Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы. 29 Для типового проектирования используются два подхода: параметри- чески-ориентированное и модельно-ориентированное проектирование. Параметрически-ориентированное проектирование включает следующие этапы: • определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач; • анализ и оценка доступных ППП по сформулированным критериям; • выбор и закупка наиболее подходящего пакета; • настройка параметров (доработка) закупленного ППП. Критерии оценки ППП делятся на следующие группы: • назначение и возможности пакета; • отличительные признаки и свойства пакета; • требования к техническим и программным средствам; • документация пакета; • факторы финансового порядка; • особенности установки пакета; • особенности эксплуатации пакета; • помощь поставщика по внедрению и поддержанию пакета; • оценка качества пакета и опыт его использования; • перспективы развития пакета. Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем. |