Лабораторная работа 1. Предпроектные исследования предметной области
 Скачать 1.4 Mb.
|
|
Решения по режимам функционирования, работы системы СУБД «Библиотека» будет функционировать в однопользовательском режиме, а также будет способна: просматривать записи базы данных (в том числе и при по мощи фильтров); добавлять новые записи; удалять записи; при входе в систему будет запрашиваться пароль. Решения по численности, квалификации и функциям персонала АС. Указанные решения должны удовлетворять требованиям, приведенным в техническом задании на разработку с'истемы. Состав функций комплексов задач, реализуемых системой Автоматизированная система должна выполнять следующие функции: сделать запись о пенсионном удостоверении; удалить информацию о пенсионном удостоверении; выдать справку о всех пенсионных удостоверениях; зарегестрировать новое предприятие в ПФ РФ; удалить предприятие из базы данных; выдать справку обо всех предприятиях, зарегистрированных в ПФ РФ; 65 подсчитать пенсию для работников предприятий на основании стажа; выдать справку о пенсионных накоплениях работника. Решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации Для реализации АС будет использоваться среда программирования Boland Delphi 7.0 и язык программирования Object Pascal. Для подсчета пенсии будет использоваться следующий алгоритм. Вначале определяется стажевый коэффициент пенсионера. Он полагается равным 0,55 за общий трудовой стаж до текущей даты не менее 25 лет мужчинам и 20 лет женщинам. За каждый полный год стажа сверх указанного стажевый коэффициент увеличивается на 0,01, но не более чем на 0,20. Затем определяется отношение заработка пенсионера к среднемесячной заработной плате в стране. Этот заработок может быть взят за этот отсчетный период или за любые 60 месяцев работы подряд, или тот, из которого была исчислена пенсия на момент реформы. Среднемесячная зарплата в стране берется за тот же самый период. Отношение заработков учитывается в размере не свыше 1,2. Для пенсионеров, проживающих на Крайнем Севере, учитываемое соотношение выше: от 1,4 до 1,9 в зависимости от установленного в централизованном порядке районного коэффициента к зарплате. Затем стажевый коэффициент умножается на соотношение заработков и на 1671 руб. — утвержденную для расчетов среднемесячную зарплату в стране за III квартал 2001 г. Это и будет пересчитанный размер трудовой пенсии по новому законодательству в обычном случае. Если он оказался менее 660 руб., то размер пенсии «доводится» до этого гарантированного минимума. Если пенсионер является инвалидом I группы или достиг к 1 января 2002 г. возраста 80 лет и более, рассчитанный в этом порядке размер пенсии по старости увеличивается на 450 руб. Если у пенсионера имеются лица, находящиеся на его иждивении, то рассчитанный размер пенсии увеличивается на 150 руб. на каждого иждивенца, но не более чем на трех в общей сложности. Источники разработки Данный документ разрабатывался на основании ГОСТ 34.698—90 на написание ТЗ на автоматизированные системы управления от 01.01.1992 г. Приложения СОСТАВИЛИ Должность исполнителя Фамилия, имя, отчество Подпись Дата « ______ » 2013 г. Должность исполнителя Фамилия, имя, отчество Подпись Дата « _______ » 2013 г. 66 Пример 2. РД 50-34.698-90 Пояснительная записка к эскизному проекту на создание автоматизированной системы (пример эскизного проекта) Ниже представлен пример (образец) проектного документа «Пояснительная записка к эскизному проекту на создание автоматизированной системы», основанный на методических указаниях РД 50-34.698-90. Данный документ формируется IT-специалистом на стадии эскизного проектирования информационной системы. В качестве примера разработки информационной системы взят проект внедрения информационно-аналитической системы «Корпоративное хранилище данных». На странице ниже приведен содержание пояснительной записки эскизного проекта в соответствии с ГОСТ, внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделен вертикальной чертой). Разделы пояснительной записки: 1. Общие положения 2. Основные технические решения Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости Решения по режимам функционирования, диагностированию работы системы Решения по персоналу и режимам его работы Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество Состав функций, комплексов задач реализуемых системой Состав и размещение комплексов технических средств Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам Методы и средства разработки 3. Мероприятия по подготовке объекта автоматизации к вводу системы в действие 67 Пояснительная записка к эскизному проекту на создание автоматизированной системы «Корпоративное хранилище данных» 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 1.4 Цели, назначение и область использования системы Определяются цели (чего хочет достичь организация Заказчика от внедрения системы); назначение (для каких пользователей предназначена); области использования АИС (какие виды деятельности организации Заказчика охватывает система). Информация для разделов "Наименование системы", "Основания для проведения работ", "Наименование организаций Заказчика и Разработчика", "Цели, назначение и область использования системы" берется из одноименных разделов технического задания на создание корпоративного хранилища данных. 1.5. Нормативные ссылки При эскизном проектировании использовались следующие нормативно-технические документы: Например: 1. Техническое задание на создание информационной системы КХД ( http://www.prj-exp.ru/patterns/pattern_tech_task.php ) 2. ГОСТ 34 -... 3. ... 1.6 Очередность создания системы Указывается очередность создания системы и характеристики каждой очереди (функциональность, ограничения, сроки, исполнители) (). 68 http://www.prj-exp.ru/dwh/dwh_stages_of_development.php Например: Ниже представлена предполагаемая очередность создания системы: Производится разработка модели хранилища данных ( http://www.prj-exp.ru/dwh/dwh_model_types.php ). Согласовываются форматы и структуры обмена данными с системами-источниками. Проектируются процессы сбора данных в область временного хранения данных. Проектируются процессы загрузки данных в область постоянного хранения данных. Проектируются типовые отчеты. Разрабатывается схема организации доступа пользователей. Производится настройка активного сетевого оборудования. Производится настройка аппаратно-технической части: установка и настройка серверов, подключение к сетевому активному оборудованию, настройка сетевых параметров и т.п. Разрабатывается план установки серверного программного обеспечения. Производится установка серверного программного обеспечения. Реализация ... Тестирование ... 2. Основные технические решения 2.1. Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы 2.1.1 Логическая и компонентная архитектура системы Приводится перечень, назначение и взаимосвязи готовых (закупаемых) и вновь разрабатываемых программных компонентов системы. Например: Перечень используемых для создания системы КХД программных средств приведен ниже: СУБД (название, версия); ETL приложение (название, версия); BI приложение (название, версия). Логическая и компонентная архитектура системы представлена на рисунке ниже. 69 В состав разрабатываемой системы будут включены следующие технологические компоненты: программное обеспечение поддержки модели данных; ETL-приложение – это комплексное решение, с помощью которого реализуются процессы извлечения, проверки, преобразования и загрузки данных. сервер БД представляет собой промышленную систему управления базами данных. сервер приложений – продукт, обеспечивающий поддержку промышленной инфраструктуры бизнес-приложений. Включает в себя следующий ряд приложений, обеспечивающих стандартные подходы к организации служб каталогов; развертывание сервисов анализа и отчетности. средства администрирования и разработки – набор программных продуктов, предназначенных для администрирования системы ETL, базы данных, сервера приложений и разработки отчетности и дополнительных приложений клиентские места сотрудников (внутри локальной вычислительной сети), представляющие собой автоматизированные рабочие места. 2.1.2. Функциональная структура системы В данном разделе формируется схема функциональной структуры системы КХД. Схема формируется следующим образом: в виде общего прямоугольника изображается система КХД, далее в этот прямоугольник вставляются прямоугольники, обозначающие подсистемы. Внутри каждой подсистемы формируется перечень функций, которые она выполняет (перечень подсистем и перечень выполняемых ими функций берутся из раздела технического задания « Требования к функциям, выполняемым системой »). После этого на основании требований, изложенных в пункте технического задания « Требования к информационному обмену между 70 компонентами системы », прорисовываются связи между подсистемами и связи подсистем с внешними информационными системами и пользователями (к каким подсистемам обращаются пользователи). Возле каждой подсистемы схематично изображается еѐ администратор. Например: Ниже рисунка приводится описание каждой подсистемы. Описание берется из пункта « Требования к структуре и функционированию системы » технического задания. Описание подсистем может быть скорректировано. Затем производится описание взаимосвязей между подсистемами. Описание взаимосвязей формируется путем ответа на вопрос: «Какой процесс определяет взаимосвязь между каждой из подсистем?». Например: Связь «Подсистема сбора, обработки и загрузки данных - Подсистема хранения данных» определяет процесс загрузки данных в ХД. Загрузка данных происходит по протоколу <указать протокол> в определенные временные интервалы и с заданной периодичностью. После описания взаимосвязей подсистем в табличной форме приводится описание связей «Подсистема-Пользователь». В данной таблице отражается информация о том, какой администратор/пользователь работает с какой подсистемой - в матрице ставится крестик на нужном пересечении Подсистема-Пользователь. 2.2. Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости Определяются решения по взаимосвязям системы КХД со смежными системами, обеспечению ее совместимости (описание используемых протоколов обмена данными и средства и методы обмена данными). За основу берутся данные из пункта « Требования к характеристикам взаимосвязей со смежными системами » технического задания. Например: Приводится перечень смежных систем, способы их взаимодействия. Наименование смежной системы Предпочтительный способ взаимодействия 71 Информационная система управления предприятием Использование ПБД Информационно-справочная система Файлы ОС определенного формата Ниже представлена общая схема взаимодействия системы КХД и смежных систем. 2.3 Решения по режимам функционирования, диагностированию работы системы На основании пункта « Требования к режимам функционирования » технического задания приводятся режим работы системы КХД. Также приводится описание решений по диагностированию системы, осуществляемых путем установления и изучения признаков, которые характеризуют состояние системы, для предсказания возможных отклонений и предотвращения нарушений нормального режима ее работы. Например: Предлагается следующая реализация решений по режимам функционирования системы: Основной режим, в котором все подсистемы выполняют свои основные функции. Профилактический режим, в котором одна или все подсистемы не выполняют своих функций. В данный режим работы система переходит в следующих случаях: возникновение необходимости модернизации аппаратно-программного комплекса; возникновение необходимости проведения технического обслуживания; выход из строя аппаратно-программного комплекса, вызванный выходом из строя элементов аппаратной или программной базы; выход из строя сети передачи данных и другие аварийные ситуации. 72 В основном режиме функционирования система обеспечивает: работу пользователей в режиме – 24 часа в день, 7 дней в неделю (24х7); - выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности по показателям. В профилактическом режиме система обеспечивает возможность проведения следующих работ: - техническое обслуживание; модернизацию аппаратно-программного комплекса; устранение аварийных ситуаций. Принимается предварительное решение о том, что общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (XX часов в месяц). Принимается предварительное решение о том, что для обеспечения высокой надежности функционирования как системы в целом, так и ее отдельных компонентов необходимо проводить регулярное диагностирование состояния компонентов. В таблице ниже представлены средства диагностики по подсистемам. Подсистема Средства диагностирования Подсистема сбора, обработки и загрузки данных ETL Administrator – диагностика и настройка ETL- приложения, управление критериями извлечения, установка NLS; ETL Manager - просмотр и редактирование репозитория. Подсистема хранения данных DB Manager – диагностика и настройка и конфигурация одной или более БД Подсистема отображения отчетности BI Administrator – диагностика и настройка бизнес-описания и представления витрин данных Далее для каждой подсистемы приводятся примерные сценарии проведения еѐ диагностирования. Чтобы описать сценарии диагностирования необходимо ответить на следующие вопросы: «Кем проводится диагностирование?», «Какое программное обеспечение используется?», «Какие действия (действия прописываются общие, например, зайти, открыть, проверить) необходимо провести для диагностирования?», «Что необходимо проверить? (например, наличие свободного места на дисках)», «Как часто необходимо выполнять данные действия?». Необходимо также указывать критичность подсистемы для функционирования системы в целом. Например: Подсистема сбора, обработки и загрузки данных : администратор подсистемы должен каждый день контролировать работоспособность серверной части прикладного программного обеспечения сбора, обработки и загрузки данных, т.к. данная 73 подсистема является критичной для работоспособности системы в целом; администратор подсистемы перед началом загрузки данных должен проводить контроль объема свободного места на дисках для временных файлов; администратор подсистемы должен каждый день проводить анализ протоколов работы подсистемы на наличие ошибок и предупреждений, возникающих при ее работе. 2.4. Решения по персоналу и режимам его работы На основании пункта « Требования к численности персонала » технического задания приводятся соответствующие решения по численности , квалификации и функциям персонала создаваемой системы, режимам работы персонала. В данном разделе также формируется таблица с возможными вариантами привязки ролей пользователей и администраторов системы к организационной структуре Заказчика. Например: Роль Подразделение Конечный пользователь Аналитическое управление Администратор подсистемы сбора, обработки и загрузки данных Департамент информационных технологий Администратор подсистемы хранения данных Департамент информационных технологий 2.5 Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество Приводится таблица трассировки требований, заданных в техническом задании, и описанных проектных решений (достигается, нет, в какой степени, за счет чего?). Например: Требование Метод реализации Взаимодействие со смежными системами Реализуется за счет наличия интерфейсов с системами – источниками данных. Планируется использование промежуточных баз данных; интеграция «точка – точка» (point-to-point); интерактивная загрузка информации из файлов определенного формата. Диагностирование системы Реализуется путем определения перечня работ по диагностированию подсистем. Сохранение работоспособности Реализуется путем разработки процедур резервного копирования, подготовки персонала, 74 системы в различных вероятных условиях использования современных методов разработки и проверенных на практике стандартных программных средств. На объекте автоматизации обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР в соответствии с утвержденными для каждого объекта ХД мероприятиями по поддержанию его работоспособности. Приводятся сведения по обеспечению заданных в техническом задании требований к функциям, выполняемым каждой подсистемой и определяющим еѐ качество. Например: Подсистема Функция Метод реализации Подсистема сбора, обработки и загрузки данных Управление процессами сбора, обработки и загрузки данных Путем внедрения комплексного ETL-приложения Запуск процессов сбора , обработки и загрузки данных из источников в ХД Путем разработки и внедрения регламентов запуска ETL- процессов Подсистема хранения данных Создание и сопровождение структур базы данных Путем применения CASE- средства и средств администрирования СУБД Осуществление резервного копирования данных Путем применения следующих видов копирования: полное холодное копирование; логическое копирование; инкрементальное копирование 2.6. Состав функций, комплексов задач реализуемых системой Приводится наименование и назначение функциональных комплексов задач системы (или по каждой подсистеме). Функциональные задачи по мере проработки проектных решений описываются в виде сценариев. Описания сценариев могут быть вынесены в приложение к пояснительной записке. Процесс формирования сценариев выполнения каждой задачи функций каждой подсистемы производится следующим образом: приводится 75 наименование подсистемы, наименование функции подсистемы, внутри каждой функции перечисляются задачи, которые выполняются в еѐ рамках (подсистемы, функции, задачи берутся из технического задания ), для каждой задачи формируется таблица вида: Подзадача Действие В данной таблице для каждой задачи приводится перечень подзадач и сценарий их выполнения. Перечень подзадач формируется следующим образом: берется наименование задачи и из названия задачи выделяются подзадачи, например задача «Поддержка (разработка, модификация) модели ХД» содержит в себе две подзадачи «Разработка» и «Модификация», задача «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» содержит в себе следующие подзадачи: «Создание нового процесса», «Редактирование процесса», «Удаление процесса» и т.п. Далее для каждой выделенной подзадачи приводится описание сценариев еѐ выполнения. Сценарий формируется путем последовательных ответов на следующие вопросы: Вопрос: «Кто производит действия для выполнения подзадачи?» Ответ: «Администратор подсистемы...» Вопрос: «Что должен сделать Администратор? К какому ПС обратиться? Какой файл выбрать?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный ... » Вопрос: «Какие действия после открытия в рамках подзадачи должен выполнить Администратор?» Ответ. «Администратор подсистемы обращается к программе ... и открывает ранее разработанный ... Администратор вносит изменения в ..., содержащие ...» Вопрос: «Какие действия выполняет сама подсистема в момент действия Администратора? Появляется ли диалоговое окно?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный .... Администратор вносит изменения в ..., содержащие .... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла ...» Вопрос: «Какие действия выполняет Администратор после появления диалогового окна?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный .... Администратор вносит изменения в ..., содержащие .... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла ... Администратор подтверждает команду сохранения.». Например, таблица, содержащая описание сценариев для подзадач задачи "Создание, редактирование и удаление процессов сбора, обработки и загрузки данных", функции "Управление процессами сбора, обработки и 76 загрузки данных", подсистемы "Подсистема сбора, обработки и загрузки данных" будет выглядеть следующим образом. 2.6.1 Подсистема сбора, обработки и загрузки данных 2.6.1.1 Функция «Управление процессами сбора, обработки и загрузки данных» Описание возможного сценария для последующей реализации задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» приведено в таблице. Подзадача Действие Создание нового процесса Администратор обращается к модулю разработки подсистемы на сервере разработки. Подсистема предоставляет инструментальные средства для создания нового процесса. Администратор подсистемы создает схему нового процесса ETL. На схеме указываются компоненты процесса: источники данных, компоненты преобразования данных, таблицы БД. Администратор подсистемы инициирует команду сохранения созданного процесса. Подсистема размещает созданный процесс на сервере среды разработки. Администратор подсистемы выполняет запуск, тестирование и отладку создаваемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности нового процесса. Готовый процесс переносится на продуктивный сервер. Редактирование процесса Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. Используя инструментальные программные средства подсистемы, Администратор изменяет схему процесса ETL, размещает измененный процесс на сервере среды разработки. Подсистема размещает редактируемый процесс на сервере среды разработки. Администратор подсистемы выполняет запуск, тестирование и отладку редактируемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности редактируемого процесса. 77 Готовый процесс переносится на продуктивный сервер. Удаление процесса Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. Используя инструментальные программные средства подсистемы, Администратор удаляет процесс ETL, размещает изменения на сервере среды разработки. Подсистема размещает внесенные изменения на сервере среды разработки. Изменения переносятся на продуктивный сервер. 2.7. Состав и размещение комплексов технических средств Решения по комплексу технических средств, его размещению на объекте. Приводится перечень серверов, рабочих мест, определяется сетевое окружение (включая технические средства), в рамках которого будет функционировать АИС, размещение на технических средствах компонентов. Например: Также определяются предварительные решения по разбивке дискового массива: тома, размеры томов, уровень RAID. Определяются предварительные решения по резервному копированию: подсистема, тип копирования (холодная копия, логическое копирование, инкрементальное копирование) и его частота, приводятся решения по архивированию копий. Приводятся предварительные решения по размещению зон разработки, тестирования и промышленной эксплуатации. 78 2.8. Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам 2.8.1 Описание информационной базы В табличном виде приводится перечень и описание предметных областей модели данных хранилища данных. Например: Предметная область Описание Анализ клиентов В данной области возможен анализ клиентов Заказчика (предприятия, организации и физические лица, потребляющие услуги Заказчика). Например, из данной области можно получить информацию на запросы следующего характера: Общие запросы по клиентам Организационно-правовая форма клиента Месторасположение клиента (страна, город, почтовый адрес) Контактная информация Классификация промышленности, к которой относится клиент Договорные отношения с клиентами прочее Ниже приводятся изображения отношений между сущностями внутри каждой предметной области. Данные изображения формируются на основе концептуальной модели. После чего в табличной форме приводится наименование и описание каждой сущности предметной области модели данных. Например: 79 Сущность модели данных Описание сущности Договора на оказание услуг (Billing Arrangement) Договора на оказание услуг, заключенные между Исполнителем и Заказчиком. ***Пример*** Договор №15 от 31.05.2006 Договор №18 от 31.07.2007 Валюта (Currency) Валюта расчетов. ***Пример*** USD, EUR, RUR 2.8.2. Решения по пользовательскому интерфейсу В данном разделе приводятся решения по организации диалогового взаимодействия с пользователями программы. Например, формируются примеры экранных форм вывода информации для каждой функциональной роли. Приводится краткое описание содержания областей экранной формы. Из пункта « Требования к численности персонала » технического задания берется список ролей администраторов системы, к ним добавляется роль «Конечный пользователь» и для каждой из роли вставляется ScreenShot соответствующего программного средства, ниже приводится его краткое описание. Например: Пример экранной формы вывода анализа данных BI средства: 1 – меню, содержащее список команд и панель инструментов. 2– интерактивное окно редактирования отчета. 3 – таблица с данными. 4 – График, отображающий те же данные, что и в таблице, но в графическом виде. 2.9 Методы и средства разработки Приводятся решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации. 80 Данный раздел формируется на основе раздела « Требования к программному обеспечению » технического задания. Уточнения данного раздела производятся путем ответа на следующие вопросы: «Какие программные средства будут использоваться для реализации системы?» «Какие операционные системы будут установлены на серверах?» «Какой язык запросов будет использоваться для работы с БД? В каком стандарте?» «Какие средства будут использоваться для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий)?» «В рамках каких стандартов будут проходит моделирование и описание? С использованием какого программного обеспечения?» «Какие средства и методы разработки программных средств будут использоваться для реализации системы?». 3. Мероприятия по подготовке объекта автоматизации к вводу системы в действие В данном разделе указывают: мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ; мероприятия по обучению и проверке квалификации персонала; мероприятия по созданию необходимых подразделений и рабочих мест; мероприятия по изменению объекта автоматизации; другие мероприятия, исходящие из специфических особенностей, создаваемых АС. Ниже представлен пример содержания данного раздела. 3.1 Мероприятия по подготовке информационной базы Приводится перечень мероприятий, которые должны быть проведены в целях приведения информации к виду, пригодному для использования системе КХД. Для этого необходимо ответить на следующий вопрос: «Какие технические решения необходимо согласовать между Разработчиком и Заказчиком?». Например, форматы взаимодействия, способы взаимодействия и т.п. 3.2 Мероприятия по подготовке персонала Разрабатывается перечень мероприятий, которые необходимо провести Заказчику в целях подготовки пользователей и обслуживающего персонала системы КХД. Например, комплектация штата, назначение ответственных и т.п. 3.3 Мероприятия по организации рабочих мест Определяется перечень мероприятий, которые должны быть проведены Заказчиком в целях организации рабочих мест разработчиков, пользователей, администраторов системы. Например, организовать подсеть разработчиков и 81 администраторов, организовать обучение и т.п. Также в этом разделе приводятся предварительные требования к рабочим местам. Например, указывается, что на рабочих станциях пользователей должен быть установлен MS Internet Explorer не ниже версии 5.5 и т.п. 3.4 Мероприятия по изменению объекта автоматизации Приводится перечень мероприятий, которые должны быть проведены силами Заказчика в целях подготовки помещений для размещения аппаратно- технического комплекса системы и организации необходимого аппаратно- технического обеспечения. Например, организовать сетевое взаимодействие, закупить оборудование и т.п. 3.5 Прочие мероприятия Указываются мероприятия по изменению объекта автоматизации, другие мероприятия, исходящие из специфических особенностей создаваемой АИС. Контрольные вопросы 1. Назовите этапы разработки программного обеспечения. 2. Что такое жизненный цикл программного обеспечения? 3. В чем заключается постановка задачи и предпроектные исследования? 4. Перечислите составляющие эскизного проекта. Время, отведенное на выполнение лабораторной работы Время, отводимое на выполнение лабораторной работы, определяется в соответствии с программой и календарно-тематическим планированием, а также сложностью программного продукта, на который разрабатывается эскизный проект Литература 1. ГОСТ 19.102-77 Единая система программной документации. Стадии разработки 2. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам 3. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению 4. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов. 5. Гагарина Л.Г, Киселев Д.В., Федотова Е.Л. Разработка и эксплуатация автоматизированных информационных систем: учеб. пособие / Под ред. Проф. Л.Г. Гагариной. – М.: ИД «ФОРУМ»: ИНФРА-М, 2011- 384с.: ил. – (Профессиональной образование) 6. Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2011. - 320 с.: ил. 7. Мезенцев К.Н. Автоматизированные информационные системы: учебник для студ. учреждений сред. проф. образования / К.Н. Мезенцев. – 2-е изд., стер. – М.: Издательский центр «Академия», 2011. – 176 с. 8. Портал нормативных документов: http://www.opengost.ru/ 82 Лабораторная работа №4. Разработка технического проекта и рабочего проекта в соответствии с ГОСТ Цель работы: Ознакомиться с процедурой разработки технического проекта и рабочего проекта на программный продукт, с применением ГОСТ 34.201-89 ИТ. Комплекс стандартов. Виды, комплектность и обозначение документов, ГОСТ 34.601-90 ИТ. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания, РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов. Основные теоретические сведения Технический проект — стадия разработки конструкторской документации на изделие или стадия создания автоматизированной системы. В более узком смысле под техническим проектом понимается совокупность технических документов, которые содержат окончательные проектные решения по изделию (системе). Технический проект системы — это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности АИС и перечень мероприятий по подготовке объекта к внедрению. На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы. Разработку технического проекта на материальные изделия осуществляют в соответствии с Единой системой конструкторской документации (ЕСКД), на автоматизированные системы — в соответствии с Комплексом стандартов на автоматизированные системы (ГОСТ 34 серии). Цель технического проекта— определение основных методов, используемых при создании информационной системы, и окончательное определение ее сметной стоимости. Техническое проектирование подсистем осуществляется в соответствии с утвержденным техническим заданием. Технический проект программной системы подробно описывает: выполняемые функции и варианты их использования; соответствующие им документы; структуры обрабатываемых баз данных; взаимосвязи данных; алгоритмы их обработки. Технический проект должен включать данные об объемах и интенсивности потоков обрабатываемой информации, количестве пользователей программной системы, характеристиках оборудования и программного обеспечения, взаимодействующего с проектируемым программным продуктом. 83 При разработке технического проекта оформляются: ведомость технического проекта. Общая информация по проекту; пояснительная записка к техническому проекту. Вводная информация, позволяющая ее потребителю быстро освоить данные по конкретному проекту; описание систем классификации и кодирования; перечень входных данных (документов). Перечень информации, которая используется как входящий поток и служит источником накопления; перечень выходных данных (документов). Перечень информации, которая используется для анализа накопленных данных; описание используемого программного обеспечения. Перечень программного обеспечения и СУБД, которые планируется использовать для создания информационной ситемы; описание используемых технических средств. Перечень ап- паратных средств, на которых планируется работа проектируемого программного продукта; проектная оценка надежности системы. Экспертная оценка надежности с выявлением наиболее благополучных участков программной системы и ее узких мест; ведомость оборудования и материалов. Перечень оборудования и материалов, которые потребуются в ходе реализации проекта. Структурная схема Структурной называют схему, отражающую состав и взаимодействие по управлению частями разрабатываемого программного обеспечения. Структурная схема определяется архитектурой разрабатываемого ПО. Функциональная схема Функциональная схема — это схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Разработка алгоритмов Метод пошаговой детализации реализует нисходящий подход к программированию и предполагает пошаговую разработку алгоритма. Структурные карты Методика структурных карт используется на этапе проектирования ПО для того, чтобы продемонстрировать, каким образом программный продукт выполняет системные требования. Структурные карты Константайна предназначены для описания отношений между модулями. Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных. 84 Технический проект на автоматизированную систему (ГОСТ 34) Работы по созданию (развитию) автоматизированной системы, выполняемые на стадии «Технический проект», регламентируются документом ГОСТ 34.601-90 и в общем случае содержат следующие этапы: 1. Разработка проектных решений по системе и еѐ частям. 2. Разработка проектной документации на автоматизированную систему и еѐ части. 3. Разработка и оформление документации на поставку изделий для комплектования автоматизированной системы и (или) технических требований (технических заданий) на их разработку. 4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. Перечень документов, создаваемых на стадии «Технический проект», определяется документом ГОСТ 34.201-89. Требования к содержанию документов технического проекта приведены в руководящем документе по стандартизации РД 50-34.698-90. Состав и содержание технического проекта приведены в таблице Содержание технического проекта |