не помню. Методические указания к практическим занятиям и по организации самостоятельной работы для обучающихся специальности
 Скачать 0.65 Mb.
|
Перечень практических и самостоятельных работТаблица 3 Перечень практических и самостоятельных работ
Практическое занятие №1Тема: Разработка сценария внедрения программного продукта для рабочего места. Цель: изучить основы разработки, сценарии внедрения программного продукта для рабочего места. Время выполнения: 2 часа. Теоретический материал 1.1 ГОСТ Р ИСО/МЭК 12207. Основные процессы и взаимосвязь между документами в информационной системе согласно стандартам. Стандарты в области информационных систем. Стандарты на проектирование и разработку ИС классифицируются: - по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО); - по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT Д. Росса), фирменные стандарты (Microsoft ODBC,IBM SNA); - по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель". Материалы, существенно разные по: - степени обязательности для организаций разного типа; - конкретности и детализации содержащихся требований; - открытости и гибкости, адаптируемости к конкретным условиям. Стандарты: - международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО); - стандарты комплекса ГОСТ 34 на создание и развитие АС; - Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle. Международный стандарт ISO/IEC 12207: 1995-08-01, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО. Охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ. При этом процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. Целесообразность совместного использования стандартов на АС и на ПО. Важное отличие стандарта: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.). В стандарте описаны 5 основных процессов ЖЦ ПО: - процесс приобретения; - процесс поставки; - процесс разработки; - процесс функционирования; - процесс сопровождения Описаны 4 вспомогательных процесса: Вспомогательные процессы это процессы - решения проблем, документирования, управления конфигурацией, гарантирования качества, последний из которых использует результаты остальных процессов группы обеспечения качества, в которую входят: - процесс верификации; - процесс аттестации; - процесс совместной оценки; - процесс аудита. Вспомогательные процессы поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО. Описаны 4 организационных процесса: процесс управления; процесс создания инфраструктуры; процесс усовершенствования; процесс обучения. К ним примыкает особый процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта. Особенности стандарта: "Динамический" характер стандарта, заключающийся в такой последовательности выполнения процессов и задач, при которой один процесс при необходимости вызывает другой или его часть. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте. Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует ее в деталях. В нем не описано как реализовать или выполнить услуги и задачи, включенные в процессы. Он не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт. Особенности стандарта: Гарантирование качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты. Степень обязательности: после решения организации о применении ISO12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые составляют согласованность с этим стандартом. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать БД вовсе. Стандарты комплекса ГОСТ34 описание. ГОСТ34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Объектами стандартизации являются АС различных видов и все виды их компонентов, а не только ПО и БД. Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). ГОСТ34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается, отталкиваясь от этого содержания. Особенности стандарта: Главный мотив разработки стандарта: разрешить проблему несовместимости. Действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС: - единая система стандартов автоматизированных систем управления (24-я система) для АСУ, ОАСУ, АСУП, АСУТП и др. организационно-экономических систем; - комплекс стандартов системы 23501, распространявшихся на САПР - системы автоматизированного проектирования; - четвертая группа 14-й системы стандартов, распространяющаяся на АС технологической подготовки производства. Пример: В качестве предметной области выбрана тема «Отдел кадров. Учет персонала». 1. Этап разработки раздела «Общие сведения»: -Полное наименование ИС: «Отдел кадров. Учет персонала». -Шифр темы: 00001. -Предприятие-разработчик системы: Лаборатория баз данных “БД”, ул. 50 лет Октября,86, тел. 32-12-02. -Предприятие-заказчик системы: ООО «ЛюксАвто». - Система создается на основании технического задания (ТЗ). ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие. Кроме того, при создании системы используются ГОСТ 34.602-89 “Техническое задание на создание автоматизированной системы”. - Плановый срок начала работ: 01.04.2021. - Плановый срок окончания работ: 31.05.2021. - Автоматизируемая система создается на коммерческой основе. - Порядок оформления и предъявления заказчику результатов работы по созданию системы определяется после получения начальной версии продукта, в которой должны быть реализованы все основные функции, определенные в ТЗ и утвержденные заказчиком. 2. Этап разработки раздела «Назначение и цели создания системы»: - Вид автоматизируемой деятельности: учет персонала в отделе кадров. - Перечень автоматизируемых процессов: учет сведений о сотрудниках, формирование и ведение личных карточек сотрудников, формирование приказов и отчетов. - Наименование и значение показателей, которые будут достигнуты в результате внедрения БД: уменьшение затрат рабочего времени на ввод, редактирование и поиск данных о сотрудниках предприятия, формирование личных карточек, приказов и отчетов, уменьшение бумажного документооборота. 3. Этап разработки раздела «Характеристики объекта автоматизации» Краткие сведения о предприятии. Отдел кадров, деятельность которого планируется автоматизировать, занимается учетом сотрудников фирмы «ЛюксАвто». Важнейшим звеном в данной деятельности являются специалисты по работе с персоналом. В зависимости от того, насколько автоматизирована их работа, можно судить об эффективности работы отдела кадров и всего предприятия в целом. Каждый день отдел кадров осуществляет операции по работе с персоналом. Сотрудник лично заполняет данные о себе. После этого специалист по работе с персоналом принимает эти данные и вносит их в базу данных. Непосредственно из базы данных берутся необходимые данные для заполнения личной карточки сотрудника, формирования приказов и отчетов. Организационная структура. Организационная структура предприятия показана на рисунке 1.  Рисунок - 1 Организационная структура предприятия. Описание автоматизируемых процессов, информационные потоки автоматизируемых процессов. Сведения о сотрудниках собираются специалистом по работе с персоналом. Вся информация хранится и обрабатывается специалистом по работе с персоналом. Некоторая информация для ведения отчетности хранится в бумажной форме. Схема информационных потоков процесса показана на рисунке 2.  Рисунок - 2 Схема информационных потоков процесса “Учет персонала”. В целом, до начала разработки данной системы вся отчетность велась путем составления личных карточек на бумажных носителях, из которых при необходимости выбирались те или иные сведения. Таким образом, видно, насколько рационально использовать базу данных и приложение по работе с ней. Во-первых, сокращается объем бумажного документооборота и время на роботу с информацией о сотрудниках, данные о любом сотруднике можно получить путем запросов, кроме того, заметно сократится время на формирование отчетов для руководства и бухгалтерии. Теперь запишем всю информацию в систематизированной форме. Далее, при создании базы данных, эту информацию можно будет разделить на конкретные таблицы. - Сотрудники. - Адрес. - Образование. - Подразделение. - Приказ о зачислении. - Штатное расписание. - Должность. - Карточка учета. 4. Этап разработки раздела «Требования к ИС» Требования к системе в целом ИС должна соответствовать требованиям технического задания на ее создание и развитие, а также требованиям нормативно-технических документов, действующих в ведомстве заказчика ИС. Ввод в действие ИС должен приводить к полезным технико-экономическим, социальным результатам: - уменьшению времени по учету данных о сотрудниках; - уменьшение времени на формирование отчетов, приказов и справок. Технические средства ИС должны быть установлены так, чтобы обеспечивались их безопасная эксплуатация и техническое обслуживание. Требования безопасности устанавливаются в инструкциях по эксплуатации технических средств. Требования к функциям (задачам), выполняемым системой Данная информационная система разрабатывается с расчетом на нескольких пользователей – специалистов по работе с персоналом. При работе с системой специалист по работе с персоналом должен решать следующие задачи: - Получать доступ к данным таблиц, в которых должна содержаться вся необходимая информация. - Просматривать данные таблиц, при необходимости редактировать их. - Создавать на основе исходных данных личные карточки сотрудников, отчеты, приказы и справки. При этом в основном используется выборка из таблиц. Таким образом, разрабатываемая система должна обеспечивать решение вышеперечисленных задач. В готовом виде она должна быть максимально простой и удобной: все операции должны выполняться с помощью элементарных действий пользователя. Здесь необходима распечатка исходных таблиц и отчетов, источниками которых являются ранее составленные запросы. Все отчеты должны оформляться в едином стиле. Требования к информационному обеспечению ИС Информационное обеспечение ИС должно включать: - данные о сотрудниках; - приказы о зачислении; - штатное расписание; - личные карточки. Требования к программному обеспечению ИС Для функционирования базы данных подходят операционные системы Windows,Vista. Диалоговый режим требует объектно-ориентированную систему программирования -BorlandDelphi , а СУБД – Access. Требования к техническому обеспечению АС Минимальные требования к техническому обеспечению АС следующие: - Pentium IV; - ОЗУ 512 Мбайт; - 10 Мбайт дисковой памяти; - принтер формата А4. 5. Этап разработки раздела «Стадии и этапы разработки» Стадии разработки Разработка должна быть проведена в три стадии: - разработка технического задания; - рабочее проектирование; - внедрение. 6. Этапы разработки На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ: - разработка модели автоматизируемых процессов и функциональной модели ИС; - разработки логической и физической моделей данных; -разработка программы; - разработка программной документации; - испытания программы. На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах заказчика. Приемо-сдаточные испытания должны проводиться на объекте заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной исполнителем и согласованной заказчиком программы и методик испытаний. Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в протоколе проведения испытаний. На основании протокола проведения испытаний исполнитель совместно с заказчиком подписывает акт приемки-сдачи программы в эксплуатацию. Внедрение системы Определенные трудности освоения системы управления проектами могут быть связаны с необходимостью внедрения и использования новых управленческих технологий. Таким образом, разработка и настройка программного обеспечения еще не дает гарантии, что данное ПО, будет эффективно применено. Процедура внедрения системы призвана помочь в преодолении данной проблемы. Масштабы использования систем управления проектами в различных организациях могут существенно варьироваться. Сложность задач по внедрению зависит от масштабов организации, имеющейся структуры управления и степени автоматизации, масштабов и типа реализуемых проектов, степени вовлеченности в управление проектами внешних организаций. Однако, даже в относительно простых ситуациях план внедрения системы может сыграть решающую роль для ее ввода в реальную эксплуатацию. Еще на стадии проектирования важно вовлечь потенциальных пользователей в процесс разработки и таким образом заручиться их поддержкой. Можно сформулировать несколько наиболее часто встречающихся ошибок планирования внедрения систем для управления проектами, которые являются причинами неудач освоения подобных систем: - цели проекта и ожидаемые результаты не определены заранее или определены не в полном объеме. Жесткие временные ограничения, нетерпеливость или непоследовательность руководства могут не позволить реализовать цели проекта в полном объеме; - планирование ввода в эксплуатацию всех функций системы управления проектами одновременно. Внедрение системы для управления проектами в полном объеме может предусматривать использование целого ряда новых технологий (например, установку глобальной информационной сети и баз данных клиент -сервер), а реализация различных функций может влиять на работу разных подразделений и специалистов (например, разные отделы должны быть вовлечены в поддержку информационных потоков при реализации временного, ресурсного и стоимостного видов планирования работ). Все это может привести к значительному усложнению проекта и делает проблематичным стабилизацию работы системы в целом. Планирование перевода сразу всей организации на использование системы для управления проектами. Это подобно попытке связать сразу всех сотрудников крупной организации в локальную вычислительную сеть. вместо того, чтобы осуществлять подключение пользователей последовательно, отдел за отделом. Таким образом, некоторые общие рекомендации по внедрению программного обеспечения для управления проектами включают следующее: Важно четко представлять преимущества, ожидаемые от внедрения новой системы. Результаты внедрения системы должны быть согласованы со всеми, кого это может касаться на разных уровнях управления в организации (как с непосредственными пользователями системы, так и с пользователями/поставщиками информации для системы). Последовательное внедрение в использование функций планирования и управления от простого к сложному. Рекомендуется начать с планирования и контроля временных параметров, затем освоить функции стоимостного планирования и контроля и только после этого переходить к ресурсному планированию. К интеграции системы управления проектами с другими системами лучше переходить после того, как процедуры использования основных ее функций освоены. Последовательное внедрение системы, начиная с отдельных небольших проектов и функциональных отделов. Начать лучше с небольшого проекта с достаточно квалифицированной командой исполнителей. Необходимо помнить, что в каждой организации есть сотрудники, более заинтересованные в использовании новых систем автоматизации и более способные в их освоении. Начать лучше именно с них. Получив первую группу пользователей, освоивших систему, можно переходить к распространению данной технологии на остальные проекты и отделы в организации. Когда система начнет реально работать в организации, противникам ее использования придется тоже перейти в ряды пользователей. Важно убедиться, что руководители отделов осведомлены о планах внедрения новой системы и действуют в соответствии с планом. План внедрения системы не должен ограничиваться лишь настройкой программного обеспечения и обучением пользователей функциям системы. Проекты по установке новых систем автоматизации управленческой деятельности традиционно охватывают гораздо более широкий спектр задач от дополнительной формализации процедур сбора и хранения управленческой информации до осуществления изменений в организационной структуре управления и перераспределения обязанностей. В общем, проекты по внедрению подобных систем можно отнести к классу организационных проектов — проектов, в той или иной степени ведущих к развитию структуры организации. Задания: 1. Рассмотрев пример, на основе своей предметной области (смотри номер варианта по учебному журналу) разработать сценарий для выбранного направления деятельности, согласно требованиям, предъявляемым к техническому заданию для информационной системы. ВАРИАНТЫ ЗАДАНИЙ: 1. Прокат автомобилей 2. Библиотечный фонд города 3. Спортивный клуб 4. Управление складом 5. Автошкола 6. Химчистка 7. Автомастерская 8. Компания по продаже мед.техники 9. Страховая компания 10. Гостиница 11. Ломбард 12. Оптовая база 13. Завод по производству металлоизделий 14. Ювелирная мастерская 15. Предприятие по организации свадебных торжеств 16. Бюро по трудоустройству 17. Нотариальная контора 18. Производство мебели 19. Производство детских игрушек 20. Поликлиника 21. Магазин розничной торговли 22. Спортивный клуб 23. Аэропорт 24. Магазин по ремонту и продаже компьютеров и комплектующих 25. Строительная организация 26. Игровая комната 27. Строительная организация 28. Фотоцентр 29. Городской аквапарк. 2. Изучить теоретический материал и ответить на контрольные вопросы. Контрольные вопросы: По какому принципу можно сгруппировать стандарты на разработку информационных систем? Приведите примеры стандартов на разработку информационных систем. В чем заключается предмет стандарта ISO/IEC 12207: 1995-08-01? На кого ориентирован стандарт ISO/IEC 12207: 1995-08-01? Опишите структуру стандарта ISO/IEC 12207: 1995-08-01? Перечислите особенности стандарта ISO/IEC 12207: 1995-08-01. Опишите предмет стандарта ГОСТ 34-601.90. На кого ориентирован стандарт ГОСТ 34-601.90? Опишите структуру стандарта ГОСТ 34-601.90. Назовите этапы описания бизнес- процесса? В чем заключается процесс внедрения ПО? Какие этапы составляют процесс внедрения? Какие сложности приходится преодолевать при внедрении ИС? Чем грозит наличие ошибок при внедрении всем участникам процесса? Рекомендуемая литература: 2 [с. 10 – 22], 3 [с. 40 – 77]. Практическое занятие №2 Тема: Разработка и оформление «Руководство оператора». Цель: формирование умений оформления «Руководство оператора». Время выполнения: 2 часа. Теоретический материал Функции оператора сопровождения и менеджера развертывания Методология внедрения ИС Весь проект разбивается на три фазы: бизнес-моделирование; тестирование; опытная эксплуатация. Сложность и масштабность процесса внедрения крупных информационных систем ERP-класса обуславливает необходимость планирования каждой фазы в отдельности – по принципу поэтапного уточнения. План внедрения носит характер не последовательного графика, а состоит из нескольких, исполняющихся зачастую параллельно друг другу, рабочих заданий. Начиная с фазы Бизнес моделирования, работы по проекту разбиваются на отдельные рабочие задания. Данные рабочие задания представляют собой план работ по достижению одной или нескольких целей проекта. Рабочее задание является основным документом контроля исполнения Исполнителем договора субподряда на оказания консалтинговых услуг. Бизнес-моделирование Цель фазы: Группа внедрения должна получить по возможности наиболее полное представление о Предприятии – достаточное для проведения полноценного тестирования будущей модели предприятия. Предприятие получает возможность уточнить и дополнить перечень целей внедрения, оценить реальность их достижения путем рассмотрения сценариев внедрения и проектного решения. Результаты: Пояснительная записка – обследование предприятия Предварительный перечень целей внедрения Предварительный план мероприятий по структурно-функциональному реинжинирингу предприятия Предварительный сценарий внедрения Проектное решение: блок-схемы бизнес – процессов; табличные описания функций; макеты выходных документов; вербальное описание методик работы с системой. Окончательный план мероприятий по структурно-функциональному реинжинирингу предприятия Уточненный сценарий внедрения (Фаза 1) Пилотное тестирование Цель фазы: Предприятие получает возможность протестировать систему, т.е. получить представление о степени готовности своих сотрудников и управляющего состава к работе в новой системе. Результаты: 1. Адаптированная бизнес-модель предприятия 2. Описание контрольного примера тестирования 3. Дополнения к проектному решению: образцы выходных форм; справочники; перечень рабочих мест системы; служебные инструкции пользователей; должностные инструкции; регламенты взаимодействия отделов; методики управления; копия приказа о порядке запуска системы в опытную эксплуатацию; акт приемки тестовой эксплуатации системы; перечень замечаний по доработке модели; приказ об учетной политике. Уточненный сценарий внедрения (Фаза 2) – план «миграции» – перехода на новую систему Внедрение и развертывание Цель фазы: Начать промышленную эксплуатацию ИСУ. Результаты: 1. Акт выверки сконвертированных данных 2. Регламенты взаимодействия ИСУ БААН с существующими системами 3. Приказы по предприятию (в соответствии с перечнем мероприятий по реинжинирингу) 4. Акт приемки системы в промышленную эксплуатацию с перечнем доработок и оценкой степени достижения поставленных целей. Методика проведения обследования бизнес-процессов компании Методика позволяет собрать и систематизировать информацию о структуре компании и ее бизнес-процессах, причем, в не зависимости от области ее деятельности и дальнейших методов оптимизации. 2.2.Типовые функции инструментария для автоматизации процесса внедрения информационной системы Аббревиатура CASE (Computer-aided Software Engineering – автоматизированная разработка ПО) обозначает специальный тип программного обеспечения, предназначенного для поддержки таких процессов создания ПО, как разработка требований, проектирование, кодирование и тестирование программ. Поэтому к CASE- средствам относятся редакторы проектов, словари данных, компиляторы, отладчики, средства построения систем и т.п. CASE-технологии предлагают поддержку процесса создания ПО путем автоматизации некоторых этапов разработки, а также создания и предоставления информации, необходимой для разработки. Приведем примеры техпроцессов, которые можно автоматизировать с помощью CASE-средств. 1. Разработка графических моделей системы на этапах создания спецификации и проектирования. 2. Проектирование структуры ПО с использованием словарей данных, хранящих информацию об объектах структуры и связях между ними. 3. Генерирование пользовательских интерфейсов на основе графического описания интерфейса, создаваемого в диалоговом режиме. 4. Отладка программ на основе информации, получаемой в ходе выполнения программы. 5. Автоматическая трансляция программ, написанных на устаревших языках программирования (например, COBOL), в программы, написанные на современных языках. В настоящее время подходящие CASE-технологии существуют для большинства процессов, выполняемых в ходе разработки ПО. Это ведет к определенному улучшению качества создаваемых программ и повышению производительности труда разработчиков программного обеспечения. Вместе с тем эти достижения значительно уступают тем ожиданиям, которые присутствовали при зарождении CASE-технологии. Тогда считалось, что стоит только внедрить CASE-средства – и можно получить весьма значительное повышение и качества программ, и производительности труда. Фактически это повышение составляет примерно 40% . Хотя и это повышение весьма значительно, CASE- технологии не совершили революции в инженерии программного обеспечения, как ожидалось. Расширение применения CASE-технологии ограничивают два фактора. 1. Создание ПО, особенно этап проектирования, во многом является творческим процессом. Существующие CASE-средства автоматизируют рутинные процессы, попытки привлечь их к решению интеллектуальных и творческих задач проектирования особым успехом не увенчались. 2. Во многих организациях-разработчиках создание ПО – результат работы команды специалистов по программному обеспечению. При этом много времени тратится на "пустое" общение между членами команды разработчиков. В этой ситуации CASE- технологии не могут предложить ничего такого, что способно повысить производительность труда разработчиков. Отомрут ли эти факторы в будущем, пока неясно. Но, на сегодняшний день маловероятно появление CASE-технологии, поддерживающих творческие элементы процесса проектирования систем и коллективный труд команды разработчиков. Однако системы поддержки общего процесса проектирования и групповой работы существуют и используются в процессе создания ПО. В настоящее время сложилась развитая индустрия CASE-средств, круг возможных поставщиков и разработчиков этих программных продуктов очень широк. 2.3. Оценка качества функционирования информационной системы. CASE технология. Качество ИС связано с дефектами, заложенными на этапе проектирования и проявляющимися в процессе эксплуатации. Свойства ИС, в том числе и дефектологические, могут проявляться лишь во взаимодействии с внешней средой, включающей технические средства, персонал, информационное и программное окружение. В зависимости от целей исследования и этапов жизненного цикла ИС дефектологические свойства разделяют на дефектогенность, дефектабельность и дефектоскопичность. Дефектогенность определяется влиянием следующих факторов: численностью разработчиков ИС, их профессиональными психофизиологическими характеристиками; условиями и организацией процесса разработки ИС; характеристиками инструментальных средств и комплексов ИС; сложностью задач, решаемых ИС; степенью агрессивности внешней среды (потенциальной возможностью внешней среды вносить преднамеренные дефекты, например, воздействие вирусов). Дефектабельность характеризует наличие дефектов ИС и определяется их количеством и местонахождением. Другими факторами, влияющими на дефектабельность, являются: структурно-конструктивные особенности ИС; интенсивность и характеристики ошибок, приводящих к дефектам. Дефектоскопичность характеризует возможность проявления дефектов в виде отказов и сбоев в процессе отладки, испытаний или эксплуатации. На дефектоскопичность влияют: количество, типы и характер распределения дефектов; устойчивость ИС к проявлению дефектов; характеристики средств контроля и диагностики дефектов; квалификация обслуживающего персонала. Оценка качества ИС - задача крайне сложная из-за многообразия интересов пользователей. Поэтому невозможно предложить одну универсальную меру качества и приходится использовать ряд характеристик, охватывающих весь спектр предъявляемых требований. Наиболее близки к задачам оценки качества ИС модели качества программного обеспечения, являющегося одним из важных составных частей ИС. В настоящее время используется несколько абстрактных моделей качества программного обеспечения, основанных на определениях характеристики качества, показателя качества, критерия и метрики. Критерий может быть определен как независимый атрибут ИС или процесса ее создания. С помощью такого критерия может быть измерена характеристика качества ИС на основе той или иной метрики. Совокупность нескольких критериев определяет показатель качества, формируемый исходя из требований, предъявляемых к ИС. В настоящее время наибольшее распространение получила иерархическая модель взаимосвязи компонентов качества ИС. Вначале определяются характеристики качества, в числе которых могут быть, например: - общая полезность; - исходная полезность; - удобство эксплуатации. Далее формируются показатели, к числу которых могут быть отнесены: - практичность; - целостность; - корректность; - удобство обслуживания; - оцениваемость; - гибкость; - адаптируемость; - мобильность; - возможность взаимодействия. Каждому показателю качества ставится в соответствие группа критериев. Для указанных показателей приведем возможные критерии. Надо отметить, что один и тот же критерий может характеризовать несколько показателей: - практичность -работоспособность, возможность обучения, коммуникативность, объем ввода, скорость ввода-вывода; - целостность -регулирование доступа, контроль доступа; - эффективность -эффективность использования памяти, эффективность функционирования; - корректность -трассируемость, завершенность, согласованность; - надежность -точность, устойчивость к ошибкам, согласованность, простоту; - удобство обслуживания -согласованность, простоту, краткость, информативность, модульность; - оцениваемость -простоту, наличие измерительных средств, информативность, модульность; - гибкость -распространяемость, общность, информатированность, модульность; - адаптируемость -общность, информативность, модульность, аппаратную независимость, программную независимость; - мобильность -информативность, модульность, аппаратную независимость, программную независимость; - возможность взаимодействия -модульность, унифицируемость процедур связи, унифицируемость данных. С помощью метрик можно дать количественную или качественную оценку качества ИС. Различают следующие виды метрических шкал для измерения критериев. Первый тип - метрики, которые используют интервальную шкалу, характеризуемую относительными величинами реально измеряемых физических показателей, например, временем наработки на отказ, вероятностью ошибки, объемом информации и других. Второй тип - метрики, которым соответствует порядковая шкала, позволяющая ранжировать характеристики путем сравнения с опорными значениями. Третий тип - метрики, которым соответствуют номинальная, или категорированная шкала, определяющая наличие рассматриваемого свойства или признака у рассматриваемого объекта без учета градаций по этому признаку. Так, например, интерфейс может быть "простым для понимания", "умеренно простым", "сложным для понимания". В настоящее время не существует стандартов, полностью удовлетворяющих оценке качества ИС. В западноевропейских странах имеется ряд стандартов, определяющих основы сертификации программных систем. Стандарт Великобритании (BS750) описывает структурные построения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Развитием иерархического подхода является представленная на рис.3 модель классификации критериев качества информационных систем. С помощью функциональных критериев оценивается степень выполнения ИС основных целей или задач. Конструктивные критерии предназначены для оценки компонент ИС, не зависящих от целевого назначения.  Рисунок 3 - Модель классификации критериев качества информационных систем Имеется международный аналог указанного стандарта (ISO9000) и аналог для стран-членов НАТО (AQAP1). Существующая в нашей стране система нормативно-технических документов относит программное обеспечение к "продукции производственно-технического назначения", которая рассматривается как материальный объект. Однако программное обеспечение является скорее абстрактной нематериальной сферой. Существующие ГОСТы (например, ГОСТ 28195-89 "Оценка качества программных средств. Общие положения") явно устарели и являются неполными. Стандарты управления качеством промышленной продукции Международные стандарты серии ISO 9000 разработаны для управления качеством продукции, их дополняют стандарты серии ISO14000, отражающие экологические требования к производству промышленной продукции. Хотя эти стандарты непосредственно не связаны с CALS- стандартами, их цели -совершенствование промышленного производства, повышение его эффективности -совпадают. Очевидно, что управление качеством тесно связано с его контролем. Контроль качества традиционно основан на измерении показателей качества продукции на специальных технологических операциях контроля и выбраковке негодных изделий. Однако есть и другой подход к управлению качеством, который основан на контроле качественных показателей не самих изделий, а проектных процедур и технологических процессов, используемых при создании этих изделий. Такой подход во многих случаях более эффективен. Он требует меньше затрат, поскольку позволяет обойтись без стопроцентного контроля продукции и благодаря предупреждению появления брака снижает производственные издержки. Именно этот подход положен в основу стандартов ISO 9000, принятых ISO в 1987 г. и проходящих корректировку приблизительно каждые пять лет. Стратегия CALS предполагает два этапа создания единого информационного пространства: - автоматизация отдельных процессов жизненного цикла изделия и представление данных о них в электронном виде согласно международным стандартам; - интеграция автоматизированных процессов и относящихся к ним данных в составе единого информационного пространства. Для реализации стратегии CALS используются следующие методы: 1. Технологии анализа и реинжиниринга бизнес-процессов - методы реструктуризации функционирования предприятия. Эти технологии позволяют корректно перейти от бумажного к электронному документообороту и внедрить в процессе автоматизации новые методы разработки изделий (параллельное проектирование, междисциплинарные рабочие группы и т. п.). 2. Технологии представления данных об изделии - методы стандартизированного представления в электронном виде данных, относящихся к отдельным процессам ЖЦ изделия (1-й этап создания информационного пространства). 3. Технологии интеграции данных об изделии - методы интеграции автоматизированных процессов ЖЦ и относящихся к ним данных (2-й этап формирования ИП). Для интеграции всех данных в рамках ИП применяются системы управления данными об изделии. Их задача - аккумулировать всю информацию, создаваемую прикладными системами, в единую модель. Процесс взаимодействия этих систем и прикладных систем строится на основе стандартных интерфейсов, которые условно можно разделить на четыре группы: 1. Функциональные стандарты - отслеживают организационную процедуру взаимодействия компьютерных систем. Например в стандарте IDEF (Integrate Computer Automated Manufacturing DEFinition - семейство методов и технологий для создания сложных систем и проектирования компьютерных систем), IDEF0 – моделирование функций. 2. Информационные стандарты - предлагают модель данных, используемую всеми участниками жизненного цикла. Например, ISO 10303 STEP. 3. Стандарты на программную архитектуру - задают архитектуру программных систем, необходимую для организации взаимодействия без участия человека. Например, COBRA. 4. Коммуникационные стандарты - указывают способ физической передачи данных по локальным и глобальным сетям. Например, Интернет-стандарты. CALS-методология независима от предметной области и активно применяется при создании сложной наукоемкой продукции как военного, так и гражданского назначения, срок жизни которой, с учетом различных модернизаций, составляет десятки лет. Как правило, она разрабатывается с привлечением многочисленных субподрядчиков, и философия CALS подразумевает прозрачные и легкие коммуникации исполнителей друг с другом и покупателями. 2.4. Организация процесса обновления в информационной системе. Регламенты обновления. Обновление – это дополнение к программному обеспечению, которое предотвращает или устраняет неполадки в нем. Помимо этого, оно также повышает безопасность, а также улучшает производительность компьютера. Обновления программного обеспечения расширяют функциональность системы и устраняют несовместимость с программным/аппаратным обеспечением. Своевременное выполнение обновлений поможет избежать следующих негативных последствий: развитие информационной системы под требования бизнеса только за счет собственных разработок; увеличение количества собственных разработок приводит только к установке нот и обновлений, устраняющих ошибки и необходимых для выполнения требований изменения законодательства. Со временем установка таких обновления становится все более трудоемкой; увеличение стоимости поддержки информационных систем; завершение поддержки производителей устаревших баз данных и операционных систем; снижение общего уровня безопасности системы. Типы обновлений. Частичное обновление Каждое частичное обновление, выданное разработчиком, должно иметь ссылку на задачу, в которой описана проблема. Обновление ставится сначала на тестовую базу. Проверяется работоспособность функционала, по задаче, созданной на ресурсе. После установки обновления на тестовую базу, в случае соответствия функционала, описанному в задаче, обновление устанавливается на рабочую базу и ожидает проверки конечного пользователя. Частичное обновление выкладывается в случае возникновения критической ошибки в работе функционала, а так же при потребности передачи функционала до установки полного обновления. Полное обновление В зависимости от потребности может собираться как полное квартальное обновление, так и полное промежуточное. Промежуточное Обновление выкладывается в отдельную задачу для установки на тестовую базу (содержит описание и список задач по фильтру). В первый рабочий день обновление устанавливается на тестовую базу данных. Срок тестирования 2 дня. В случае обнаружения критических ошибок срок установке сдвигается до их исправления. Квартальное Обновление выкладывается в отдельную задачу для установки на тестовую базу. В течение 3х дней обновление должно быть установлено на тестовую базу. Тестовую базу перед установкой обновления следует актуализировать до состояния рабочей базы данных на текущий момент. Со дня установки релиза начинается тестирование согласно Приложению 1 к регламенту Тестирования и установки обновлений (срок тестирования 15 рабочих дней.) Простое обновление Процесс обновления систем заключается в последовательном выполнении этапов. Обследование. На этом этапе определяется уровень обновлений системы, подключение дополнительных функциональных возможностей. Проводится сбор информации об объеме внедрения бизнес-процессов, операций по ним и определяется объем тестирования. Также осуществляется анализ объема, модифицированного ПО и собственных разработок. Подготовка плана перехода. Производится подготовка тестовой системы (копия продуктивной), ее обновление, анализ и корректировка затронутого модифицированного ПО; тестирование работы системы, регистрация и решение проблем; создание перечня мероприятий для перехода. Затем проводится повторное разворачивание тестовой системы, ее обновление, тестирование и применение плана мероприятий. Производится планирование сроков этапов перехода, оценка рисков и возможность дополнительных мероприятий по их снижению. В итоге определяется период неработоспособности продуктивной системы, разрабатывается и утверждается документ «План перехода» Выполнение плана перехода. Заключается в последовательном выполнении мероприятий, описанных в документе "План перехода". Поддержка пользователей. После переноса обновлений в продуктивную систему заказчика осуществляется оперативная поддержка пользователей и решение оставшихся проблем. Миграция Процесс миграции систем включает в себя несколько этапов. Обследование. На этом этапе определяется перечень мероприятий. Подготовка плана миграции. Производится применение перечня мероприятий, подготовка стенда, проверяется работоспособность системы. Затем проводится тестовая миграция, в ходе которой уточняется, обновляется перечень мероприятий, а также определяется их длительность. На основе результатов этого процесса производится планирование сроков этапов миграции, оценка рисков и возможность дополнительных мероприятий по их снижению. В итоге определяется период неработоспособности продуктивной системы, разрабатывается и утверждается документ «План перехода» Выполнение плана миграции. Заключается в последовательном выполнении мероприятий, описанных в документе. Поддержка пользователей. После миграции осуществляется оперативная поддержка пользователей и решение оставшихся проблем. Требования к содержанию и оформлению отчета по практическому заданию Руководство оператора должно состоять из следующих частей: - Титульной; - Информационной; - Основной. Титульная часть оформляется согласно ГОСТ 19.104-78 ЕСПД. Основные надписи. Информационная часть должна состоять из аннотации и содержания. В аннотации приводят сведения о назначении документа и краткое изложение основной части. Содержание включает перечень записей о структурных элементах основной части документа. Назначение программы содержит сведения о назначении программы и информацию, достаточную для понимания функций программы. Условия выполнения программы должны содержать минимальный и максимальный состав аппаратурных и программных средств. Выполнение программы представляет собой последовательность действий оператора, обеспечивающих загрузку, выполнение и завершение программы, возможные варианты команд, которыми оператор может управлять выполнением программы, а также ответы программы на эти команды. Сообщения оператору содержат тексты сообщений, выдаваемых в ходе выполнения программы и соответствующие действия оператора, его действия в случае сбоя, повторного запуска программы. Задания: 1. Составить руководство оператора по выбранной тематике ИС согласно выбранной тематики практического задания №1 а также требований к содержанию и оформлению отчета по практическому заданию п.п.2.4. 2. Изучить теоретический материал по темам 2.1., 2.4 и ответить на контрольные вопросы. Контрольные вопросы: На какие фазы разбит процесс внедрения ПО? Какие этапы составляют процесс внедрения? Как можно кратко охарактеризовать этап Бизнес-моделирование? Как можно кратко охарактеризовать этап Тестирование? Как можно кратко охарактеризовать этап Опытная эксплуатация? Какие преимущества и недостатки имеет концепция автоматизированной разработки ПО? Какие этапы составляют процесс внедрения? Какие существуют виды инструментария внедрения? Как можно кратко охарактеризовать понятие CASE технология? Какие этапы создания ПО подразумевает CASE технология? Какие факторы имеют дефектологические методы оценки? Назовите характеристики качества? Назовите критерии качества? Что такое CALLS технологии? Для чего необходимы стандарты качества? Что такое обновление ИС? Охарактеризуйте каждый из типов обновлений? Какие достоинства и недостатки имеет процесс обновления? Что такое миграция ПО? Рекомендуемая литература: 2 [с. 77 – 101], 3 [с. 146 – 247]. Практическое задание №3 |