Понятие Системы также неисчерпаемо и бесконечно, как бесконечна и неиссчерпаема Вселенная. 1 Проф. Семенов М. А. , каф. УПП. 01. 09. 2011.
1 ЧАСТЬ 1. Система, информация, энергия 2 Часть 2. Технические и программные средства информационных технологий 3 Часть 3. Управление в сложных системах 4 Часть 4. Системы автоматизации управленческой деятельности. 5 Часть 5. Фазы инвестиционного проекта 2
1 Часть 5. 2 Общесистемные принципы создания ИАИСУ 3 Фазы инвестиционного проекта 4 Технико-экономическое обоснование (ТЭО) 5 Техни ческое зада ние 6 7 8 9 10 ГОСТЫ на технические задания Программа работ Эскизный проект Технический проект Сдача системы в эксплуатацию 11 Порядок контроля и приемки 12 Предварительные испытания системы 13 Опытная эксплуатация 14 Приемочные испытания 15 Программа и методика проведения испытаний системы 16 Перечень этапов испытаний и проверок 3
Часть 5. Общесистемные принципы создания ИАИСУ При создании ИАСУ должны соблюдаться следующие принципы: • системный подход к созданию ИАСУ; • непосредственное участие первого руководителя в создании ИАСУ; • максимальная типизация проектных решений; • непрерывное развитие ИАСУ; • комплексная разработка задач и рабочих программ; • минимизация ввода и вывода информации; • согласованность пропускных способностей отдельных частей ИАСУ; • мотивации труда разработчиков ИАСУ и специалистов, ее эксплуатирующих. Организация разработки СУ представляет собой комплекс научно исследовательских, проектных, инженерно технических и организационных работ, направленных на совершенствование существующей или вновь создаваемой СУ с применением СВТ, математических и современных методов 4 управления.
Фазы инвестиционного проекта Прединвестиц ионная Инвестиционная Эксплуатац ионная (опер я) Предварительное знакомство и оценка инвестиционных возможностей; анализ и выбор эффективного варианта; подготовка ПТЭО, ТЭО; разработка ТЗ; принятие решения об инвестировании. Создание правовой, финансовой, организационной основы; разработка эскизного проекта; разработка технического проекта; разработка рабочего проекта; заключение контрактов; строительство (реконструкция) зданий и сооружений; приобретение оборудования; набор и обучение персонала. Сдача в эксплуатацию системы управления; внедрение проекта; модернизация и расширение системы управления. Взаимосвязь отдельных фаз инвестиционного проекта с сетевым графиком создания системы управления 7 8 9 3 0 1 5 2 4 6 10 14 16 15 11 12 13 5 17
• Прединвестиционная фаза начинается с предварительного знакомства с будущей системой, отвечающей рыночным условиям, и оценкой инвестиционных возможностей для определенной организации (работа 0 1). Подготовку технико экономического обоснования (ТЭО) работы 2 3, осуществляет коллектив разработчиков системы с привлечением эко номистов и финансистов. При этом определяются цели, критерии эффективности и ограничения, существующие во внешней и внутренней среде организации. Следующим этапом является разработка технического задания (ТЗ) работа 2 4, в котором описываются основные характеристики будущей системы, сроки разработки и эффективность производимых затрат. Завершающей работой прединвестиционной фазы создания системы управления является принятие инвестиционного решения (работа 4 5) Инвестиционная фаза. Эта фаза проекта начинается с формирования правовой, финансовой и организационной основы (работа 5 6), являющейся базой для проектирования будущей системы. Для сложных систем, не имеющих аналогов, осуществляется эскизное проектирование (работа 6 7). После утверждения ТЗ формируются группы специалистов, каждая из которых уточняет перечень задач по функциональным подсистемам, их постановку и алгоритмизацию. Эти группы работают в тесном контакте с разработчиками информационной 6 подсистемы, проводя взаимное согласование состава и характеристик входных и выходных сигналов
• Совокупность проводимых работ по организации и созданию СУ удобно представлять в виде сетевых моделей (графиков). Детальные сетевые графики содержат сотни и тысячи операций, вид которых определяется в значительной степени сложностью создаваемой системы и спецификой организации, для которой она проектируется. • Обоснованность проводимых расчетов при построении сетевых графиков определяется точностью исходных данных. Достоверные оценки продолжительности работ могут быть получены на основе предварительно созданных нормативов трудоемкости по отдельным работам. • Под инвестиционным циклом понимается время, необходимое для реализации прединвестиционной, инвестиционной и эксплуатационной (оперативной) фаз проекта. • ТЭО представляют собой комплекс расчетно аналитических документов, которые должны содержать исходные данные и основные оценочные показатели, с помощью которых рассчитывается эффективность будущих инвестиционных проектов. • Техническое задание на систему управления представляет собой утвержденный в установленном порядке документ, определяющий цели, требования и основные исходные данные для ее разработки. Здесь же дается предварительная оценка эффективности 7 будущей системы управления.
Отдельные группы специалистов создают технический (раб. 6 8) и рабочий проект (раб. 6 9). На этапе рабочего проектирования кроме разработчиков системы в работе принимают участие программисты и специалисты по техническим средствам. На основе разработанных технического и рабочего проекта происходит процесс заключения контрактов с поставщиками технических средств и других материальных ресурсов (работа 6 10). Для размещения технических средств и обслужи вающего персонала в необходимых случаях осуществляется строительство новых зданий и сооружений. В большинстве случаев происходит реконструкция уже существующих площадей (работа 6 11). Приобретение оборудования (работа 6 12) происходит после того, как появляются необходимые площади для его размещения. Выполнение большого количества работ при эксплуатации системы управления требует большого количества обслуживающего персонала. Для этого идет набор необходимого персонала , его обучение и переподготовка уже 8 имеющихся кадров (работа 6 13).
• Эскизный проект представляет собой описание предлагаемой системы управления. В нем рассматриваются варианты структурной схемы, состав и способы формирования информационной базы данных, укрупненные схемы алгоритмов обработки данных. • Технический проект. В техническом проекте содержится документация, содержащая общесистемные проектные решения, алгоритмы решения задач, окончательную оценку эффективности будущей системы. Технический проект разрабатывается на основе утвержденного ТЗ. • Рабочий проект представляет собой техническую документацию, содержащую программное обеспечение решаемых задач и их комплексов, детализированные общесистемные проектные решения • Эксплуатационная (оперативная) фаза. Ее начало проводится после официального утверждения рабочего проекта, наличия оборудования и обслуживающего персонала (раб. 13 14). Сдача в эксплуатацию СУ (раб. 14 15) характеризуется передачей обслуживающему персоналу уже отработанных составных частей системы. Внедрение проекта (раб. 15 16) происходит в течение определенного времени и зависит от уровня его подготовленности, а также качества выполненных работ. При эксплуатации системы может появиться необходимость ее 9 частичной модернизации или существенной реконструкции (работа 16 17).
ТЕХНИКО ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ (ТЭО) ИЛИ КОМУ НУЖЕН БИЗНЕС ПЛАН (БП) БП это эффективный инструмент привлечения инвестиций, так как он позволяет не только оценить рентабельность будущего инвестиционного проекта, но также позволяет инвестору понять размер инвестиций, источники возврата средств и сроки окупаемости будущего бизнес проекта. БП нужен тому, кто будет вкладывать деньги в инвестиционный проект. Главная цель БПа это доказать частному инвестору, что изложенная в нем бизнес идея нова, перспективна и прибыльна. А для банков главное понять, что БП доходчиво и грамотно объясняет им откуда предприятие будет вовремя и в полном объеме погашать кредит. Для самого же предприятия БП это с профессиональной точки зрения понять о перспективности будущего бизнеса и оценить объем инвестиций. Что такое БП предприятия Нельзя рассматривать БП, как только документ состоящий из финансового плана и маркетинговых исследований. Структуру БПа обобщенно можно представить в виде нескольких модулей, которые взаимосвязаны. Прежде всего это маркетинговые исследования рынка. Только грамотное проведение маркетинговых исследований о текущем состоянии может дать ответ о возможности реализовать будущий продукт на рынке. Но также маркетинговые исследования дают очень ценную информацию для разработки БПа и составления технико экономического обоснования (ТЭО) финансовой модели будущего проекта. Например, сезонность, которая может очень существенно 10 влиять на рентабельность и окупаемость инвестиционного проекта.
Далее, самым ключевым блоком в БПе является Финансовый план (ФП), который состоит из вводных данных, прямых и косвенных затратах, объеме производства, баланса, прибыли убытки, кэш фло, оценки рисков проекта и вывода о сроке окупаемости инвестиционного проекта, уровне рентабельности и объемах инвестиций. Только на основании этих данных производится оценка всего инвестиционного проекта о его целесообразности. В свою же очередь ФП строится исходя из результатов маркетингового исследования. Производственный план является также существенным в БПе блоком, особенно если это касается организации нового производства. Зачем составлять БП. Для того чтобы инвестиционный проект был реализован, необходимо еще на стадии подготовки БПа продумать все организационные и технические вопросы, схемы финансирования проекта, спланировать весь будущий бизнес, оценить инвестиционные затраты. БП может помочь не только объяснить инвестору суть будущего проекта, но и самому предприятию указать на некоторые ключевые моменты, которые не были ранее заметны. Для банков же БП часто является основанием для расчетов кредитных рисков, размере кредитной линии и процентной ставки. Ведь в финансовой модели БПа указывается не только размер кредита, но также кредитная ставка и график привлечения и погашения кредита. Для внутреннего использования, когда не стоит цель привлечения кредита в проект, БП также может быть очень ценен. Еще на стадии составления БПа собственник предприятия может сделать выводы о 11 целесообразности бизнес идеи и сэкономить значительные денежные средства.
12
Примерный вариант структуры ТЭО инвестиционного проекта 1. Резюме проекта • наименование проекта; • цели проекта; • инициатор проекта; • организация управления проектом; • продукция проекта и рынок сбыта; • производственная программа; • место расположения объектов проекта; • технология и технологическое оборудование; • график осуществления проекта; • основные финансово экономические показатели проекта 2. Рыночная ориентация проекта • рынок проекта и оценка его состояния; • описание продукции, ее конкурентоспособности; • эксплуатационные преимущества продукции; • технологические преимущества продукции; • система ценообразования на продукцию; • сбыт продукции 3. Выбор технологии производства и оборудования • обоснование выбора поставщиков; • описание технологии; • описание структуры и состава оборудования; • спецификация оборудования 4. Место размещения • требования к территории; • ситуационный план; • инженерная инфраструктура; • климатические и инженерно геологические условия 5. Мощность оборудования и производственная программа проекта 13 • обоснование выбора мощности оборудования; • производственная программа
6. Потребность в сырье и материалах • номенклатура и технические требования к сырью и материалам; • цены на сырье и материалы; • расчет потребности в сырье и материалах по годам; • транспортная схема поставок сырья и материалов; • потребность в сырье и материалах 7. Потребность в кадрах и их обучение 8. Организация строительства и график осуществления проекта 9. Экологическая оценка и природоохранные мероприятия 10. Взаимодействие с местными властями и общественностью 11. Управление проектом • общая концепция проекта; • управление на стадии подготовки; • управление проектом на стадии реализации; • управление проектом на стадии эксплуатации 12. Затраты на подготовку проекта • прединвестиционные расходы; • затраты на разработку рабочего проекта; • согласование и экспертиза рабочего проекта; • представительские расходы; • администрационные затраты; • затраты на проведение тендера; • платежи за участие в реконструкции инженерных коммуникаций; • затраты на получение прав долгосрочной аренды 14 земельного участка 13. Капитальные вложения по проекту
14. Расчет текущих издержек • затраты на закупку сырья; • затраты на доставку сырья и продукции; • обслуживание автотранспорта; • содержание зданий и сооружений; • арендные платежи за землю; • коммунальные платежи; • заработная плата обслуживающего персонала; • хозяйственные расходы; • прочие расходы; • текущий ремонт оборудования; • расходы по страхованию; • расходы на рекламу; • услуги сторонних организаций 15. Налоговое окружение проекта 16. Финансирование проекта • источники и структура финансирования проекта; • условия внешнего финансирования; • расчет финансовых издержек; • схема и организация финансирования 17. Оценка рисков и мероприятия по их ограничению 18. Финансово экономическая оценка проекта 19. Основные выводы 20. Информация о разработчиках ТЭО 15
Техни ческое зада ние (ТЗ, техзада ние) — исходный документ для проектирования социотехнической системы, сооружения, гражданского или промышленного комплекса (вкл. инфраструктуру), конструирования технического устройства (прибора, машины, системы управления и т. д. ), разработки информационных систем, стандартов либо проведения научно исследовательских работ (НИР). ТЗ содержит основные требования, предъявляемые к объекту проектирования (социальной системе, сооружению, изделию или услуге) и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п. ) документации, её состав, сроки исполнения и т. д. , а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования. 16
Как инструмент коммуникации в связке "заказчик исполнитель", техническое задание позволяет: обеим сторонам: § представить образ готового решения; § выполнить поэтапную проверку готового продукта (приёмочное тестирование — проведение испытаний); § снизить вероятность рисков и ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний) заказчику: § осознать, что именно ему нужно: в т. ч. опираясь на существующие на данный момент технические возможности и свои ресурсы; § требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ: исполнителю: § понять суть задачи, показать заказчику «технический облик» будущей системы, изделия, программного изделия или автоматизированной системы; § спланировать выполнение проекта и работать по намеченному плану; § отказаться от выполнения работ, не указанных в ТЗ Техническое задание — исходный документ, определяющий порядок и условия проведения работ по Договору, содержащий цель, задачи, принципы выполнения, ожидаемые результаты и сроки выполнения 17 работ.
ГОСТы на технические задания Куст есть совокупность веток, произрастающих из одной точки. Военная мудрость После тяжких трудов (и страданий) увидели свет, как минимум, три документа, соответствующие весьма условному делению продуктов человеческой жизнедеятельности: ГОСТ 2. 114 95 Единая система конструкторской документации. Технические условия; ГОСТ 19. 201 78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению; ГОСТ 34. 602 89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Примечания: Существуют и иные отечественные ГОСТ, содержащие требования к содержанию и оформлению документа «Техническое задание» . Сей факт обусловлен спецификой предметных областей. Перечисленная тройка была и остается общей для всех предметных областей; Техзадание было и остается основополагающим 18 документом, той самой «точкой опоры» , из которой все и произрастает.
Что общего в разделах перечисленных выше документов? Любое техническое задание должно содержать разделы, отражающие сведения: • что надо сделать; • для чего, с какой целью надо сделать это; • где, в какой области применения, на каком объекте это должно решать задачи и выполнять свои функции; • какие требования будут предъявлены к этому; • какие работы потребуется выполнить, чтобы сделать это; • каков порядок проведения испытаний и приемки сдачи работ заказчику; • как должно быть задокументировано проведение работ; • и, наконец, на основании каких нормативно технических документов должны проводиться работы? Потребовалось разработать техническое задание на изделие пользуемся ГОСТ 2. 114 95, Надо ТЗ автоматизированную систему открываем ГОСТ 34. 602 89. На программу ГОСТ 19. 201 78. 19
20
Разработка технического задания Титульный лист «Утверждаю» «Согласовано» Директор ИРЗ Проректор ИРГТУ Максименко В. Н. Евстафьев С. Н. Техническое задание На разработку интегрированной системы управления ИРЗ «Согласовано» «Согласовано» Начальник Зав. кафедрой УПП отдела АСУ ИРЗ факультета Би. У (ФИО) Щадов И. М. Иркутск 2005 г. 21
Оглавление 1. Введение (цели и задачи, основание для разработки) 2. Описание объекта управления 3. Технические требования 4. Программа работ 5. Требования к технической документации. 6. Сдача в опытно промышленную эксплуотацию. 7. Программа и методика испытаний. 8. Документы подтверждающие выполнение договора.
Разработка технических требований Титульный лист «Утверждаю» «Согласовано» ГЛ. инженер ИРЗ Проректор ИРГТУ Максименко В. Н. Евстафьев С. Н. Технические требования к интегрированной системе управления ИРЗ «Согласовано» «Согласовано» Начальник Зав. кафедрой УПП отдела АСУ ИРЗ факультета Би. У (ФИО) Щадов И. М. Иркутск 2005 г. 23
Технические требования Оглавление 1. Назначение 2. Условия эксплуотации 3. Технические требования. Содержательное описание 4. Технические требования технические параметры и ограничения 5. Состав изделия, основные узлы, основные технические решения. 6. Технические требования к технологии изготовления 7. Техническая документация
Программа работ № Этапы работ Срок испол нения Стоим ость. Тыс. руб. Докум. Подтвер. Окончани е этапа 1 Обследование объекта управления 29. 12. 75 Отчет Разработка и согл. Техн. 15. 02. Требований к ИСУ 13 50 Согл. ТТ 50 Согл. ТЗ 2 3 4 Разработка и согл. Технического задания 15. 03. 13 Разработка архитектуры 15. 03. системы 13 4. 1. Разработка структуры БД 4. 2. Определение основных Бизнес-процессов 4. 3. 5 Разработка технической документации 5. 1. Эскизный проект Согл. ЭП 5. 2. Рабочий проект Согл. РП 6. 15. 04. 13. Разработка программы и 30. 04. методики испытаний 13 Согласова нная Пи. М 7. Опытная эксплуатация ИСУ 15. 05. 13 Протокол испытаний 8. Опытно промышлен. Испытания АСУ 15. 06. 13 Протокол испытаний 9. Сдача системы в эксплуатацию 30. 06. 13 25 АКТ сдачи в эксплуат.
1. Эскизный проект (ЭП) создается на основе ТЗ, укрупненно описывает управленческие и информационные взаимосвязи в системе. После согласования ЭП можно начинать детальное проектирование и внедрение выделенных подсистем (по бизнес процессам и/или подразделениям) с целью сокращения сроков получения реальной отдачи от внедряемых технологий. В соответствии с согласованной очередностью внедрения разрабатываются детальные ТЗ на подсистемы и проводятся работы по внедрению подсистем вплоть до завершения опытной эксплуатации. Основная работа, необходимая для разработки ТЗ будет проведена при выборе системы, т. е. на этом этапе необходимо окончательно согласовать и утвердить детали, касающиеся подсистем. На каждую подсистему оформляется и утверждается ТЗ, которое определяет порядок создания и требования к подсистеме. 26
ЭСКИЗНЫЙ ПРОЕКТ РД 50 34. 698 90 Пояснительная записка к эскизному проекту на создание автоматизированной системы (пример эскизного проекта) основанный на методических указаниях РД 50 34. 698 90. Данный документ формируется IT специалистом на стадии эскизного проектирования информационной системы. В качестве примера разработки информационной системы взят проект внедрения информационно аналитической системы «Корпоративное хранилище данных» . Разделы пояснительной записки: Общие положения Основные технические решения структура системы, подсистем, средства и способы связи для информационного обмена между компонентами системы взаимосвязь АС со смежными системами, обеспечению ее совместимости режимам функционирования, диагностированию работы системы персонал и режимы его работы Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество Состав функций, комплексов задач реализуемых системой Состав и размещение комплексов технических средств Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам Методы и средства разработки Мероприятия по подготовке объекта автоматизации к вводу 27 системы в действие
Пояснительная записка к эскизному проекту на создание автоматизированной системы «Корпоративное хранилище данных» 1. Общие положения 1. 1. Наименование системы 1. 1. 1. Полное наименование системы Полное наименование корпоративное хранилище данных. 1. 1. 2. Краткое наименование системы Краткое наименование КХД, Система. 1. 2. Основания для проведения работ Указывается номер и дата договора. Перечень документов, на основании которых создается система, кем и когда утверждены документы. Например: Работа выполняется на основании договора № … от …, заключенного между … 1. 3. Наименование организаций – Заказчика и Разработчика 1. 3. 1. Заказчик: ОАО Заказчик Адрес фактический: г. Москва. . . Телефон / Факс: +7 (495) 2222222 1. 3. 2. Разработчик: ЗАО Разработчик Адрес фактический: г. Москва. . . Телефон / Факс: +7 (495) 3333333 28
1. 4 Цели, назначение и область использования системы Определяются цели (чего хочет достичь организация Заказчика от внедрения системы); назначение (для каких пользователей предназначена); области использования АИС (какие виды деятельности организации Заказчика охватывает система). Информация для разделов "Наименование системы", "Основания для проведения работ", "Наименование организаций Заказчика и Разработчика", "Цели, назначение и область использования системы" берется из одноименных разделовтехнического задания на создание корпоративного хранилища данных. 1. 5. Нормативные ссылки При эскизном проектировании использовались следующие нормативно технические документы: Например: 1. Техническое задание на создание информационной системы КХД ( «Корпоративное хранилище данных» ) 2. ГОСТ 34 . . . 3. . 1. 6 Очередность создания системы Указывается очередность создания системы и характеристики каждой очереди (функциональность, ограничения, сроки, исполнители). 29
Например: Ниже представлена предполагаемая очередность создания системы: Производится разработка модели хранилища данных. Согласовываются форматы и структуры обмена данными с системами источниками. Проектируются процессы сбора данных в область временного хранения данных. Проектируются процессы загрузки данных в область постоянного хранения данных. Проектируются типовые отчеты. Разрабатывается схема организации доступа пользователей. Производится настройка активного сетевого оборудования. Производится настройка аппаратно технической части: установка и настройка серверов, подключение к сетевому активному оборудованию, настройка сетевых параметров и т. п. Разрабатывается план установки серверного программного обеспечения. Производится установка серверного программного обеспечения. . . Реализация. . . Тестирование. . . 30
2. Технический проект должен включать основные технические решения: данные об объемах и интенсивности потоков обрабатываемой информации, количестве пользователей ИСУ и характеристиках требуемого оборудования и программного обеспечения. На данном этапе проводится реализация/настройка программного продукта, осуществляется работа по созданию дополнительных модулей в соответствии с техническим проектом, например, реализация модулей сопряжения с системой управления технологическими процессами, создание конвертеров, позволяющих преобразовать нормативно справочную информацию и другие хранимые данные из существующей системы в требуемый формат. С самого начала работ по настройке/реализации интегрированной системы управления проводится обучение проектной группы заказчика, которая впоследствии будет сопровождать создаваемую систему. 31
2. Основные технические решения 2. 1. Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы 2. 1. 1 Логическая и компонентная архитектура системы Приводится перечень, назначение и взаимосвязи готовых (закупаемых) и вновь разрабатываемых программных компонентов системы. Например: Перечень используемых для создания системы КХД программных средств приведен ниже: - СУБД (название, версия); - ETL приложение (название, версия); - BI приложение (название, версия). Логическая и компонентная архитектура системы представлена на рисунке ниже. 32
В состав разрабатываемой системы будут включены следующие технологические компоненты: программное обеспечение поддержки модели данных; ETL приложение – это комплексное решение, с помощью которого реализуются процессы извлечения, проверки, преобразования и загрузки данных. сервер БД представляет собой промышленную систему управления базами данных. сервер приложений – продукт, обеспечивающий поддержку промышленной инфраструктуры бизнес приложений. Включает в себя ряд приложений, обеспечивающих стандартные подходы к организации служб каталогов; развертывание сервисов анализа и отчетности. средства администрирования и разработки – набор программных продуктов, предназначенных для администрирования системы ETL, базы данных, сервера приложений и разработки отчетности и дополнительных приложений. клиентские места сотрудников (АРМы внутри 33 локальной вычислительной сети),
2. 1. 2. Функциональная структура системы В данном разделе формируется схема функциональной структуры системы КХД. Схема формируется следующим образом: в виде общего прямоугольника изображается система КХД, далее в этот прямоугольник вставляются прямоугольники, обозначающие подсистемы. Внутри каждой подсистемы формируется перечень функций, которые она выполняет (перечень подсистем и перечень выполняемых ими функций берутся из раздела технического задания «Требования к функциям, выполняемым системой» ). После этого на основании требований, изложенных в пункте технического задания «Требования к информационному обмену между компонентами системы» , прорисовываются связи между подсистемами и связи подсистем с внешними информационными системами и пользователями (к каким подсистемам обращаются пользователи). Возле каждой подсистемы схематично изображается её администратор. Например: Ниже рисунка приводится описание каждой подсистемы. Описание берется из пункта «Требования к структуре и 34 функционированию системы» технического задания. Описание подсистем может быть скорректировано.
Затем производится описание взаимосвязей между подсистемами. Описание взаимосвязей формируется путем ответа на вопрос: «Какой процесс определяет взаимосвязь между каждой из подсистем? » . Например: Связь «Подсистема сбора, обработки и загрузки данных Подсистема хранения данных» определяет процесс загрузки данных в ХД. Загрузка данных происходит по протоколу <указать протокол> в определенные временные интервалы и с заданной периодичностью. После описания взаимосвязей подсистем в табличной форме приводится описание связей «Подсистема Пользователь» . В данной таблице отражается информация о том, какой администратор/пользователь работает с какой подсистемой в матрице ставится крестик на нужном пересечении Подсистема Пользователь. 35
2. 2. Определяются решения по взаимосвязям системы КХД со смежными системами, обеспечению ее совместимости (описание используемых протоколов обмена данными и средства и методы обмена данными). За основу берутся данные из пункта «Требования к характеристикам взаимосвязей со смежными системами» технического задания. Например: Приводится перечень смежных систем, способы их взаимодействия. Ниже представлена общая схема взаимодействия системы КХД и смежных систем. 36
2. 3 Решения по режимам функционирования, диагностированию работы системы приводятся на основании пункта «Требования к режимам функционирования» ТЗ на КХД. Здесь же приводится описание решений по диагностированию системы, осуществляемых путем установления и изучения признаков, которые характеризуют состояние системы, для предотвращения возможных отклонений и нарушений нормального режима ее работы. Например: Основной режим, в котором все подсистемы выполняют свои основные функции. Профилактический режим, в котором одна или все подсистемы не выполняют своих функций. В данный режим работы система переходит в следующих случаях: возникновение необходимости модернизации аппаратно программного комплекса; возникновение необходимости проведения технического обслуживания; выход из строя аппаратно программного комплекса, вызванный выходом из строя элементов аппаратной или программной базы; выход из строя сети передачи данных и т. п. ситуации. В основном режиме функционирования система обеспечивает: работу пользователей в режиме – 24 часа в день, 7 дней в неделю (24 х7); выполнение функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности. В профилактическом режиме система обеспечивает возможность проведения следующих работ: техническое обслуживание; 37 модернизацию аппаратно программного комплекса; устранение аварийных ситуаций.
Принимаются предварительные решения: - общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (XX часов в месяц). - для обеспечения высокой надежности функционирования как системы в целом, так и ее отдельных компонентов необходимо проводить регулярное диагностирование состояния компонентов. В таблице ниже представлены средства диагностики по подсистемам. Далее для каждой подсистемы приводятся примерные сценарии проведения её диагностирования. Чтобы описать сценарии диагностирования необходимо ответить на следующие вопросы: «Кем проводится диагностирование? » , «Какое программное обеспечение используется? » , «Какие действия (действия прописываются общие, например, зайти, открыть, проверить) необходимо провести для диагностирования? » , «Что необходимо проверить? (например, наличие свободного места на дисках)» , «Как часто необходимо выполнять данные действия? » . Необходимо также указывать критичность подсистемы для функционирования системы в целом. Подсистема Средства диагностирования Подсистема сбора, обработки и загрузки данных ETL Administrator – диагностика и настройка ETL-приложения, управление критериями извлечения, установка NLS; ETL Manager - просмотр и редактирование репозитория. Подсистема хранения данных DB Manager – диагностика и настройка и конфигурация одной или более БД Подсистема отображения отчетности 38 BI Administrator – диагностика и настройка бизнес-описания и представления витрин данных
Например: Подсистема сбора, обработки и загрузки данных: администратор подсистемы должен каждый день контролировать работоспособность серверной части прикладного программного обеспечения сбора, обработки и загрузки данных, т. к. данная подсистема является критичной для работоспособности системы в целом; администратор подсистемы перед началом загрузки данных должен проводить контроль объема свободного места на дисках для временных файлов; администратор подсистемы должен каждый день проводить анализ протоколов работы подсистемы на наличие ошибок и предупреждений, возникающих при ее работе. 2. 4. Решения по персоналу и режимам его работы На основании пункта «Требования к численности персонала» технического задания приводятся соответствующие решения по численности, квалификации и функциям персонала создаваемой системы, режимам работы персонала. В данном разделе также формируется таблица с возможными вариантами привязки ролей пользователей и администраторов системы к организационной структуре Заказчика. Например: Роль Подразделение Конечный пользователь Аналитическое управление Администратор подсистемы сбора, обработки и загрузки данных Департамент информационных технологий Администратор подсистемы хранения данных Департамент 39 информационных технологий . . .
2. 5 Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество Приводится таблица трассировки требований, заданных в техническом задании, и описанных проектных решений (достигается, нет, в какой степени, за счет чего? ). Например: Требование Метод реализации Реализуется за счет наличия интерфейсов с системами – источниками данных. Планируется Взаимодействие со использование промежуточных баз данных; смежными интеграция «точка – точка» (point-to-point); системами интерактивная загрузка информации из файлов определенного формата. Диагностирование системы Реализуется путем определения перечня работ по диагностированию подсистем. Реализуется путем разработки процедур резервного копирования, подготовки персонала, использования современных методов разработки и проверенных на практике Сохранение стандартных программных средств. работоспособности На объекте автоматизации обязательно системы в ведение журналов инцидентов в электронной различных форме, а также графиков и журналов вероятных условиях проведения ППР в соответствии с утвержденными для каждого объекта ХД мероприятиями по поддержанию его работоспособности. . . . 40
Приводятся сведения по обеспечению заданных в техническом задании требований к функциям, выполняемым каждой подсистемой и определяющим её качество. Например: Подсистема сбора, обработки и загрузки данных Функция Метод реализации Управление процессами Путем внедрения сбора, обработки и комплексного ETLзагрузки данных приложения Запуск процессов сбора, Путем разработки и обработки и загрузки внедрения регламентов данных из источников в запуска ETL-процессов ХД. . . Создание и Путем применения CASEсопровождение структур средства и средств базы данных администрирования СУБД Подсистема хранения данных Путем применения следующих видов Осуществление копирования: полное резервного копирования холодное копирование; данных логическое копирование; инкрементальное копирование. . . 41
2. 6. Состав функций, комплексов задач реализуемых системой Приводится наименование и назначение функциональных комплексов задач системы (или по каждой подсистеме). Функциональные задачи по мере проработки проектных решений описываются в виде сценариев. Описания сценариев могут быть вынесены в приложение к пояснительной записке. Процесс формирования сценариев выполнения каждой задачи функций каждой подсистемы производится следующим образом: приводится наименование подсистемы, наименование функции подсистемы, внутри каждой функции перечисляются задачи, которые выполняются в её рамках (подсистемы, функции, задачи берутся из технического задания), для каждой задачи формируется таблица вида: В данной таблице для каждой задачи приводится перечень подзадач и сценарий их выполнения. Перечень подзадач формируется следующим образом: берется наименование задачи и из названия задачи выделяются подзадачи, например задача «Поддержка (разработка, модификация) модели ХД» содержит в себе две подзадачи «Разработка» и «Модификация» , задача «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» содержит в себе следующие подзадачи: «Создание нового процесса» , «Редактирование процесса» , «Удаление процесса» и т. п. Подзадача Действие . . . 42
Далее для каждой выделенной подзадачи приводится описание сценариев её выполнения. Сценарий формируется путем последовательных ответов на следующие вопросы: Вопрос: «Кто производит действия для выполнения подзадачи? » Ответ: «Администратор подсистемы. . . » Вопрос: «Что должен сделать Администратор? К какому ПС обратиться? Какой файл выбрать? » Ответ: «Администратор подсистемы обращается к программе. . . и открывает ранее разработанный. . . » Вопрос: «Какие действия после открытия в рамках подзадачи должен выполнить Администратор? » Ответ. «Администратор подсистемы обращается к программе. . . и открывает ранее разработанный. . . Администратор вносит изменения в. . . , содержащие. . . » Вопрос: «Какие действия выполняет сама подсистема в момент действия Администратора? Появляется ли диалоговое окно? » Ответ: «Администратор подсистемы обращается к программе. . . и открывает ранее разработанный. . Администратор вносит изменения в. . . , содержащие. . Подсистема запрашивает необходимость сохранения работы в виде рабочего файла. . . » Вопрос: «Какие действия выполняет Администратор после появления диалогового окна? » Ответ: «Администратор подсистемы обращается к программе. . . и открывает ранее разработанный. . Администратор вносит изменения в. . . , содержащие. . Подсистема запрашивает необходимость сохранения работы в виде рабочего файла. . . Администратор 43 подтверждает команду сохранения. » .
2. 6. 1 Подсистема сбора, обработки и загрузки данных Описание возможного сценария для последующей реализации задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» приведено в таблице. Подзадача Действие - Администратор обращается к модулю разработки подсистемы на сервере разработки. - Подсистема предоставляет инструментальные средства для создания нового процесса. - Администратор подсистемы создает схему нового процесса ETL. На схеме указываются компоненты процесса: источники данных, компоненты преобразования данных, таблицы БД. Создание - Администратор подсистемы инициирует команду сохранения нового созданного процесса - Подсистема размещает созданный процесс на сервере среды разработки. - Администратор подсистемы выполняет запуск, тестирование и отладку создаваемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности нового процесса. - Готовый процесс переносится на продуктивный сервер. - Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. - Используя инструментальные программные средства подсистемы, Администратор изменяет схему процесса ETL, размещает измененный процесс на сервере среды разработки. Редактиро - Подсистема размещает редактируемый процесс на сервере среды вание разработки. процесса - Администратор подсистемы выполняет запуск, тестирование и отладку редактируемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности редактируемого процесса. - Готовый процесс переносится на продуктивный сервер. - Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. - Используя инструментальные программные средства подсистемы, Удаление Администратор удаляет процесс ETL, размещает изменения на процесса 44 сервере среды разработки. - Подсистема размещает внесенные изменения на сервере среды разработки. - Изменения переносятся на продуктивный сервер.
2. 7. Состав и размещение комплексов технических средств. Решения по комплексу технических средств, его размещению на объекте. Приводится перечень серверов, рабочих мест, определяется сетевое окружение (включая технические средства), в рамках которого будет функционировать АИС, размещение на технических средствах компонентов. Также определяются предварительные решения по разбивке дискового массива: тома, размеры томов, уровень RAID. Определяются предварительные решения по резервному копированию: подсистема, тип копирования (холодная копия, логическое копирование, инкрементальное копирование) и его частота, приводятся решения по архивированию копий. 45 Приводятся предварительные решения по размещению зон разработки, тестирования и промышленной эксплуатации.
2. 8. Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам 2. 8. 1 Описание информационной базы В табличном виде приводится перечень и описание предметных областей модели данных хранилища данных. Например: Предметная Описание область В данной области возможен анализ клиентов Заказчика (предприятия, организации и физические лица, потребляющие услуги Заказчика). Анализ клиентов . . . Например, из данной области можно получить информацию на запросы следующего характера: - Общие запросы по клиентам - Организационно-правовая форма клиента - Месторасположение клиента (страна, город, почтовый адрес) - Контактная информация - Классификация промышленности, к которой относится клиент - Договорные отношения с клиентами 46 - прочее. . .
После чего в табличной форме приводится наименование и описание каждой сущности предметной области модели данных. Например: 2. 8. 2. Решения по пользовательскому интерфейсу В данном разделе приводятся решения по организации диалогового взаимодействия с пользователями программы. Например, формируются примеры экранных форм вывода информации для каждой функциональной роли. Приводится краткое описание содержания областей экранной формы. Из пункта «Требования к численности персонала» технического задания берется список ролей администраторов системы, к ним добавляется роль «Конечный пользователь» и для каждой из роли вставляется Screen. Shot соответствующего программного средства, ниже приводится его краткое описание. Например: Пример экранной формы вывода анализа данных BI средства: 1 – меню, содержащее список команд и панель инструментов. 2 – интерактивное окно редактирования отчета. 47 3 – таблица с данными. 4 – График, отображающий те же данные, что и в таблице, но в
2. 9 Методы и средства разработки Приводятся решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации. Данный раздел формируется на основе раздела «Требования к программному обеспечению» ТЗ. Уточнения данного раздела производятся путем ответа на следующие вопросы: «Какие программные средства будут использоваться для реализации системы? » «Какие операционные системы будут установлены на серверах? » «Какой язык запросов будет использоваться для работы с БД? В каком стандарте? » «Какие средства будут использоваться для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий)? » «В рамках каких стандартов будут проходит моделирование и описание? С использованием какого программного обеспечения? » «Какие средства и методы разработки программных средств будут использоваться для реализации системы? » . 48
3. Сдача системы в эксплуатацию 3. 1. Пробное внедрение предлагаемой технологии управления проводится в ручном режиме по выбранным направлениям деятельности. По результатам опробования производятся необходимые изменения. 3. 2. Пробные пуско-наладочные работы проводят на стендовом (обособленном) оборудовании с тем, чтобы не мешать текущему процессу управления. Для проведения пробной пуско наладки от компании назначают освобожденную группу, состоящую из перспективных сотрудников, которые освобождаются от текущей производственной нагрузки. Освобожденная группа в дальнейшем участвует в обучении остальных сотрудников и распространении настроенного пакета по всем рабочим местам. 3. 3. Мероприятия по подготовке объекта автоматизации к вводу системы в действие В данном разделе указывают мероприятия по: приведению информации к виду, пригодному для обработки на ЭВМ; обучению и проверке квалификации персонала; созданию необходимых подразделений и рабочих мест; изменению объекта автоматизации; другие мероприятия, исходящие из специфических 49 особенностей, создаваемых АС.
Ниже представлен пример содержания данного раздела. 3. 3. 1 Мероприятия по подготовке информационной базы Приводится перечень мероприятий, которые должны быть проведены в целях приведения информации к виду, пригодному для использования системе КХД. Для этого необходимо ответить на следующий вопрос: «Какие технические решения необходимо согласовать между Разработчиком и Заказчиком? » . Например, форматы взаимодействия, способы взаимодействия и т. п. 3. 3. 2 Мероприятия по подготовке персонала Разрабатывается перечень мероприятий, которые необходимо провести Заказчику в целях подготовки пользователей и обслуживающего персонала системы КХД. Например, комплектация штата, назначение ответственных и т. п. 3. 3. 3 Мероприятия по организации рабочих мест Определяется перечень мероприятий, которые должны быть проведены Заказчиком в целях организации рабочих мест разработчиков, пользователей, администраторов системы. Например, организовать подсеть разработчиков и администраторов, организовать обучение и т. п. Также в этом разделе приводятся предварительные требования к рабочим местам. Например, указывается, что на рабочих станциях пользователей должен быть установлен MS Internet Explorer не ниже версии 5. 5 и т. п. 50
3. 3. 4 Мероприятия по изменению объекта автоматизации Приводится перечень мероприятий, которые должны быть проведены силами Заказчика в целях подготовки помещений для размещения аппаратно технического комплекса системы и организации необходимого аппаратно технического обеспечения. Например, организовать сетевое взаимодействие, закупить оборудование и т. п. 3. 3. 5 Прочие мероприятия Указываются мероприятия по изменению объекта автоматизации, другие мероприятия, исходящие из специфических особенностей создаваемой АИС. 51
Пробная пуско наладка включает следующие этапы: · обучение освобожденной группы; · техническая настройка типовых рабочих мест; · пробная конвертация данных и дополнительные работы; · пробный ввод в действие. Основной задачей этапа опытной эксплуатации является доводка настроенного при пробных работах пакета модулей и распространение его по всем рабочим местам компании. Подготовка и передача заказчику рабочего проекта на ИСУ Основные пусконаладочные работы включают следующие стадии: · обучение пользователей рабочих мест; · доводка технической настройки на рабочих местах; · промышленная конвертация данных; · проведение опытной эксплуатации. По результатам опытной эксплуатации составляется акт о сдаче в промышленную эксплуатацию. На этом проект внедрения ИСУ на предприятии, как правило, считается завершенным. В дальнейшем в течение нескольких месяцев производится авторская поддержка эксплуатации ИСУ силами собственных и приглашенных специалистов до тех пор, пока интегрированная система не станет рутинной практикой управленческих служб предприятия. 52
ЭТАП ВВОДА СИСТЕМЫ В ЭКСПЛУАТАЦИЮ (эксплуатационная фаза) ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ Ввод в действие разрабатываемой АСУТП осуществляется в соответствии с требованиями ГОСТ 34. 601 90 ЕСС АСУ "Автоматизированные системы. Стадии создания" и ГОСТ 34. 603 92 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. "Виды испытаний автоматизированных систем". Для автоматизированной системы устанавливаются следующие этапы испытаний: Предварительные испытания; Опытная эксплуатация; Приемочные испытания. Программы всех этапов испытаний составляются Разработчиком на основании документа техно рабочего проекта «Программа и методика испытаний» (ПМ)П, и утверждаются Заказчиком. 53
Программы испытаний должны предусматривать следующие виды проверок: Проверка комплектности комплекса технических с редстви стандартной технической документации; Проверка состава и содержания документации техно-рабочего проекта; Автономная проверка готовности комплекса технических средств; Метрологическая поверка измерительных каналов; Проверка отказоустойчивости и функций самодиагностики системы; Проверка реализации функций АСУТП на соответствие требованиям Технического задания; Проверка квалификации и уровня подготовки оперативного (технологического) и эксплуатационного(обслуживающего) персонала для работы в условиях функционирования АСУТП. По результатам этапов испытаний оформляются отчетные документы. К отчетным документам относятся Протоколы и отчеты о результатах испытаний. В приложения должны включаться перечни методик испытаний. 54
Согласно РД 50 34. 698 90, пункт2. 14. 17, содержание разделов методик устанавливает Разработчик. Отчетные документы подписываются членами комиссии (членами рабочих групп, сформированных из членов комиссии), и утверждаются председателем комиссии. Предварительные испытания Системы проводятся для определения ее работоспособности и возможности приемки системы в Опытную эксплуатацию. Предварительные испытания организует Заказчик, и проводит их совместно с Разработчиком. Предварительные испытания могут быть: Автономные; Комплексные. Результаты испытаний по различным этапам испытаний отражаются в Протоколах испытаний и соответствующих Отчетах. В сводном Протоколе испытаний приводится заключение о возможности приемки системы в Опытную эксплуатацию, а также перечень необходимых доработок и сроки их выполнения. Работа завершается оформлением Акта 55 приемки в Опытную эксплуатацию.
Опытная эксплуатация проводится в соответствии с Программой, в которой указываются: Условия и порядок функционирования частей Системы, и Системы в целом; Порядок устранения недостатков, выявленных в процессе Опытной эксплуатации; Продолжительность Опытной эксплуатации, достаточную для проверки правильности функционирования Системы при выполнении каждой функции и готовности персонала к работе в условиях полноценного функционирования Системы. Продолжительность Опытной эксплуатации не менее двух месяцев. Во время Опытной эксплуатации Системы ведут Рабочий журнал, в который заносят: Сведения о продолжительности функционирования Системы; Сведения об отказах, сбоях, аварийных ситуациях; Сведения об изменениях параметров объекта автоматизации; Сведения о проведенных корректировках программного обеспечения и документации; Сведения о наладке технических средств. Сведения фиксируют в Журнале с указанием даты и ответственного лица. В Журнал могут быть внесены замечания персонала об удобстве эксплуатации Системы. По результатам Опытной эксплуатации составляют Акт о завершении работ по проверке Системы в режиме Опытной эксплуатации, с заключением о 56 возможности предъявления Системы на Приемочные испытания.
Приемочные испытания должны включать проверку: Полноты и качества реализации функций при регламентированных и предаварийных значениях параметров объекта автоматизации, и в других условиях функционирования АСУТП, указанных в Техническом задании; Выполнения каждого требования, относящегося к интерфейсу Системы; Работы персонала в диалоговом режиме; Средств и методов восстановления работоспособности Системы после отказов; Комплектности и качества эксплуатационной документации. Приемочные испытания автоматизированной системы проводят в соответствии с Программой испытаний, в которой указывают: Перечень объектов, выделенных в Системе для испытаний, и перечень требований, которым должны соответствовать объекты со ссылкой на конкретные пункты ТЗ; Критерии приемки Системы и ее частей; Условия и сроки проведения испытаний; Средства для проведения испытаний; Фамилии лиц, ответственных за проведение испытаний; Методики испытаний и обработки результатов; Перечень оформляемой документации (протоколы и отчеты). 57
Приёмочные испытания АСУТП проводят для определения соответствия Техническому заданию и документации проекта. Приёмочную комиссию образуют приказом по предприятию. В состав комиссии входят представители Заказчика, Разработчика, и представители технадзора. Согласно ГОСТ 34. 603 92, Приёмочной комиссии должна быть предъявлена следующая документация: Техническое задание на создание АСУТП; Исполнительная документация по монтажу; Протокол предварительных испытаний; Программа испытаний; Акт приёмки Системы в опытную эксплуатацию; Рабочие журналы опытной эксплуатации Системы; Акт о завершении работ по проверке Системы в режиме опытной эксплуатации; Техническая и проектная документация на Систему. Перед предъявлением Системы на приемочные испытания должна быть доработана техническая и проектная документация по замечаниям Протокола предварительных испытаний, и Акта о завершении работ по проверке Системы в режиме Опытной эксплуатации. Согласно ГОСТ 34. 603 92, пункт 4. 10, протоколы отдельных проверок обобщаются в едином итоговом Протоколе, на основании которого делается заключение о возможности оформления Акта приемки АСУТП в постоянную (промышленную) эксплуатацию. 58
Допускается по решению Приемочной комиссии доработка технической документации Системы после ее ввода в действие. Сроки доработки указываются в Протоколе приемочных испытаний. Результаты приемочных испытаний оформляются: Итоговым Протоколом испытаний; Актом о приемке АСУТП в промышленную эксплуатацию, и Издается приказ "О вводе АСУТП в промышленную эксплуатацию". 59
Программа испытаний информационной системы (РД 50 34. 698 90) Опубликовано 12. 09. 2010 пользователем prjexp Программа и методика проведения испытаний системы (подсистемы) на этапе опытного функционирования предназначена для установления данных, обеспечивающих получение и проверку проектных решений, выявление причин сбоев, определение качества работ, показателей качества функционирования системы (подсистемы), проверку соответствия системы требованиям техники безопасности, продолжительность и режим испытаний. Согласно РД 50 34. 698 90 «Автоматизированные системы требования к содержанию документов» , программа испытаний содержит следующие разделы: объект испытаний цель испытаний общие положения объем испытаний условия и порядок проведения испытаний материально техническое обеспечение испытаний метрологическое обеспечение испытаний отчетность 60 приложение (методика испытаний)
Объект испытаний В разделе "Объект испытаний" указывают: полное наименование автоматизированной информационной системы, обозначение; комплектность испытательной автоматизированной информационной системы. Например: Полное наименование – корпоративное хранилище данных. Обозначение – КХД или Система. Испытаний проводятся для всех подсистем и функций Системы. Так же испытания включают проверку необходимого сетевого оборудования и каналов связи. Цель испытаний В разделе "Цель испытаний" указывают конкретные цели и задачи, которые должны быть достигнуты и решены в процессе испытаний. Например: Целью проведения испытаний является: проверка взаимодействия подсистем Системы; проверка работоспособности Системы; проверка соответствия Системы требованиям приведенным в документе «Техническое задание» ; проверка готовности Системы к проведению опытной эксплуатации или приемочных испытаний на территории Заказчика. 61
Общие положения В разделе "Общие положения" указывают: перечень руководящих документов, на основании которых проводят испытания; место и продолжительность испытаний; организации, участвующие в испытаниях; перечень ранее проведенных испытаний; перечень предъявляемых на испытания документов, откорректированных по результатам ранее проведенных испытаний. Например: Перечень руководящих документов Настоящая Программа и Методика Испытаний разработана в соответствии со следующими документами: Процедура управления внутренней нормативной документацией. Процедура управления записями в системе менеджмента качества. Типовая методика измерений и оценки эксплуатационных параметров автоматизированных информационных систем. Перечень эксплуатационных параметров автоматизированных информационных систем. ГОСТ 34. 603 92 Виды испытаний АСУ РД 50 34. 698 90 Автоматизированные системы требования к содержанию документов. ГОСТ 19. 301 79 Программа и методика испытаний. Требования к содержанию и оформлению. РД 50 34. 698 90 Методические указания, информационная технология, комплекс стандартов и руководящих 62 документов на АС, требования к содержанию документов. Техническое задание.
Место и продолжительность испытаний Испытательный стенд находится на территории Заказчика по адресу: г. Москва, ул. Ленина, д. 111. Испытания проводятся в течении X дней. Участники испытаний В испытаниях принимают участие Заказчик и Исполнитель. Допускается привлечение экспертов из сторонних организаций. Перечень ранее проведенных испытаний До начала данных испытаний тестирования или испытания Системы не проводились (или были проведены автономные, или комплексные, или опытная эксплуатация). Перечень предъявляемых на испытания документов Ниже приведен перечень программной документации, предъявляемой для использования: Паспорт. Общее описание системы. Технологическая инструкция. Руководство пользователя. Описание технологического процесса обработки данных (включая телеобработку). Инструкция по формированию и ведению базы данных (набора данных). Состав выходных данных (сообщений). Каталог базы данных. Описание программ. Текст программ. 63
Перечень этапов испытаний и проверок № 1 Объект № пункта ТЗ, требование испытаний Система в целом 4. 2. Система должна протоколировать все события, связанные с изменением своего информационного наполнения Проверка реализаци и протокол ирования изменени 4. 2. Система должна иметь я возможность в случае сбоя в информац работе восстанавливать свое ионного состояние, используя ранее наполнен ия запротоколированные Системы изменения данных 2 Система в целом 3 4. 2. Должна быть реализована задача Подсистема "Осуществление хранения логического копирования" данных функции "Осуществляет Системы резервное копирование данных" 4 5 Наимено вание испытан ия Вид испытания Количество групп журнальных файлов Время и дата последнего выполнения задачи логического Проверка копирования реализаци Статус и последнего 4. 2. Логическое копирование логическо выполнения Подсистема должно производиться го Время и дата хранения ежемесячно, каждое резервног следующего данных последнее воскресенье о выполнения Системы месяца. Во временном копирова Интервал интервале 06: 00 – 08: 00 ния повторений Подсистема 4. 1. 1. Логическое День недели хранения копирование данных должно выполнения данных производиться ежемесячно Длительность 64 Системы (в конце месяца) выполнения и т. д. Требования Оцени ваемые характ е ристик и Предва ри тельные Опытна я эксплуа тация
1 ФАЗА. Предпроектные работы Сбор информации Анализ деловых процессов Анализ Действ. Нформ. . системы Опр. Треб. к Опр. Стратег. разв. Предпр я Опр. осн. характер. будущей ИСУ Системе Упр. (СУ) Интег ванной системе Упр. (ИСУ) Оценка вариантов Реорга Рек низации ванный СУ путь Реор зации СУ Оценка вариантов развития ИСУ 65 Разв. ИСУ
2 ФАЗА. Проектирование Разр тка проекта СУ Проектирование ИСУ Проверка решений Разработка укрупненной схемы ИСУ Разработка технического задания на ИСУ Проектная Док ция к системе Упр я Техн. задание на (ИСУ) Начало Реорга низации СУ Проект. Док ция ИСУ (эскизный техничес Разарботка кий; Техн го рабочий проекта проекты) ИСУ 66
3 ФАЗА. Опытная эксплуотация, опытно промышленная, ввод в действие Подолжение реорганизации СУ Акт сдачи ИСУ опытную Экспл цию Настройка Обучение. программного Ввод Пакета. начальных Документирование данных Пробные пуско наладочные работы Опытная эксплуотация ИСУ Завершение Реорг ции СУ Опытная Эксплуат. ИСУ Обучение Пользо вателей 67 АКТ сдачи ИСУ в промыш ленную эксплуа тацию
Определение основных элементов СУ. Цель — идеальный образ желаемого, возможного, нового устойчивого состояния организации. Процесс управления — последовательность этапов формирования и осуществления воздействия для достижения цели. Метод — формализованный способ воздействия на человека и коллектив. Коммуникации — процесс воздействия, взаимодействия или противодействия в системе «человек — человек» , «человек — компьютер» посредством передачи информации. Каналы обмена материальными объектами или информацией. Задача — конкретная проблема, вытекающая из цели, требующая разрешения. Закон — необходимое и устойчивое отношение между явлениями. Законы не имеют альтернатив. Принцип — основное положение какой либо теории, учения, мировоззрения. 68 Принципы имеют альтернативы.
Функция — порученная и принятая к исполнению работа или услуга. Технология — совокупность способов, рецептов и процессов для выполнения заданных функции. Решение — результат мыслительной деятельности человека, приводящий к выводу или действиям, найденный способ устранения проблем и противоречий возникающих в процессе работы организации. Характеристики информационного обеспечения — параметры объема, ценности, достоверности, насыщенности и открытости информации. Функциональные структуры — схемы взаимодействия и функции структурных подразделений , необходимых для успешной деятельности компании. Организационные отношения — различные виды воздействий и взаимодействия между функциональными структурами и персоналом компании. Система документооборота — принятый и организации поря док передвижения и контроля обработки и исполнения входящих, исходящих 69 и внутренних документов.
Жизненный цикл изделия 70
1 Вопросы для самопроверки 2 Общесистемные принципы создания ИАИСУ 3 Фазы инвестиционного проекта 4 Технико-экономическое обоснование (ТЭО) 5 Техни ческое зада ние 6 7 8 9 10 ГОСТЫ на технические задания Программа работ Эскизный проект Технический проект Сдача системы в эксплуатацию 11 Порядок контроля и приемки 12 Предварительные испытания системы 13 Опытная эксплуатация 14 Приемочные испытания 15 Программа и методика проведения испытаний системы 16 Перечень этапов испытаний и проверок 71
72
Скачать презентацию Понятие Системы также неисчерпаемо и бесконечно как бесконечна
ИСУ Бакалавры Часть 5. 20.09.12.ppt