8.-Конспект-лекций.-МДК.4.1-Внедр-и-поддерж-ПО-КС-09.02.07_compr. Обеспечения компьютерных систем
 Скачать 427.58 Kb.
|
|
ЛЕКЦИЯ 6 Организация процесса обновления в информационной системе.Регламенты обновления. План. 1. Контрольный опрос 2. Начало эксплуатации ИС 3. Регламент доработок 4. Регламенты обновления Обновление Обновление – это дополнение к программному обеспечению, которое предотвращает или устраняет неполадки в нем. Помимо этого, оно также повышает безопасность, а также улучшает производительность компьютера. Обновления программного обеспечения расширяют функциональность системы и устраняют несовместимость с программным/аппаратным обеспечением. Своевременное выполнение обновлений поможет избежать следующих негативных последствий: развитие информационной системы под требования бизнеса только за счет собственных разработок; увеличение количества собственных разработок приводит только к установке нот и обновлений, устраняющих ошибки и необходимых для выполнения требований изменения законодательства. Со временем установка таких обновления становится все более трудоемкой; увеличение стоимости поддержки информационных систем; завершение поддержки производителей устаревших баз данных и операционных систем; снижение общего уровня безопасности системы. Типы обновлений 1 Частичное обновление Каждое частичное обновление, выданное разработчиком, должно иметь ссылку на задачу, в которой описана проблема. Обновление ставится сначала на тестовую базу. Проверяется работоспособность функционала, по задаче, созданной на ресурсе. После установки обновления на тестовую базу, в случае соответствия функционала, описанному в задаче, обновление устанавливается на рабочую базу и ожидает проверки конечного пользователя. Частичное обновление выкладывается в случае возникновения критической ошибки в работе функционала, а так же при потребности передачи функционала до установки полного обновления. 2 Полное обновление В зависимости от потребности может собираться как полное квартальное обновление, так и полное промежуточное. 2.1 Промежуточное Обновление выкладывается в отдельную задачу для установки на тестовую базу (содержит описание и список задач по фильтру). В первый рабочий день обновление устанавливается на тестовую базу данных. Срок тестирования 2 дня. В случае обнаружения критических ошибок срок установке сдвигается до их исправления. 2.2 Квартальное Обновление выкладывается в отдельную задачу для установки на тестовую базу. В течение 3х дней обновление должно быть установлено на тестовую базу. Тестовую базу перед установкой обновления следует актуализировать до состояния рабочей базы данных на текущий момент. Со дня установки релиза начинается тестирование согласно Приложению 1 к регламенту Тестирования и установки обновлений (срок тестирования 15 рабочих дней. Простое обновление Процесс обновления систем заключается в последовательном выполнении следующих этапов: Обследование. На этом этапе определяется уровень обновлений системы, подключение дополнительных функциональных возможностей. Проводится сбор информации об объеме внедрения бизнес-процессов, операций по ним и определяется объем тестирования. Также осуществляется анализ объема, модифицированного ПО и собственных разработок. Подготовка плана перехода. Производится подготовка тестовой системы (копия продуктивной), ее обновление, анализ и корректировка затронутого модифицированного ПО; тестирование работы системы, регистрация и решение проблем; создание перечня мероприятий для перехода. Затем проводится повторное разворачивание тестовой системы, ее обновление, тестирование и применение плана мероприятий. Производится планирование сроков этапов перехода, оценка рисков и возможность дополнительных мероприятий по их снижению. В итоге определяется период неработоспособности продуктивной системы, разрабатывается и утверждается документ «План перехода» Выполнение плана перехода. Заключается в последовательном выполнении мероприятий, описанных в документе "План перехода". Поддержка пользователей. После переноса обновлений в продуктивную систему заказчика осуществляется оперативная поддержка пользователей и решение оставшихся проблем. Миграция Процесс миграции систем включает в себя следующие этапы: Обследование. На этом этапе определяется перечень мероприятий. Подготовка плана миграции. Производится применение перечня мероприятий, подготовка стенда, проверяется работоспособность системы. Затем проводится тестовая миграция, в ходе которой уточняется, обновляется перечень мероприятий, а также определяется их длительность. На основе результатов этого процесса производится планирование сроков этапов миграции, оценка рисков и возможность дополнительных мероприятий по их снижению. В итоге определяется период неработоспособности продуктивной системы, разрабатывается и утверждается документ «План перехода» Выполнение плана миграции. Заключается в последовательном выполнении мероприятий, описанных в документе. Поддержка пользователей. После миграции осуществляется оперативная поддержка пользователей и решение оставшихся проблем. Контрольные вопросы: Что такое обновление ИС; Охарактеризуйте каждый из типов обновлений; Какие достоинства и недостатки имеет процесс обновления; Что такое миграция ПО. ЛЕКЦИЯ 7 Тестирование программного обеспечения в процессе внедрения и эксплуатации План. 1. Контрольный опрос 2. Алгоритмы выявления ошибок ПО 3. Процесс модернизации ИС 4. Анализ последствий применения обновлений 3. Выявление недостатков и дефектов информационной системы Очень часто в больших проектах, тестирование финального релиза не позволяет выявить все проблемные места решения. Причиной тому могут быть: огромные объемы данных на деле в «боевых» условиях, проявление уникальных сочетаний бизнес правил в реальных деловых процессах, особенности работы конкретного оборудования, специфические сочетания компонентов системы, балансирование нагрузки между распределенными узлами и т.п. Зачастую ситуация еще осложняется тем, что внедрение новых систем на начальных стадиях ни в коей мере не отменяет необходимость производить работы на старых системах. То есть пользователи дублируют данные в обоих системах. Иногда требуется миграция существующих актуальных данных из устаревших хранилищ в новые, а структура и формат информации обычно весьма и весьма отличаются. Например, если в новой структуре данных не хватает информации для заполнения обязательных реквизитов, они заполняются какими-то данными назначенными «по умолчанию», а потом уже корректируются вручную пользователями. И это только малая толика того, с чем приходится сталкиваться в реальных проектах. Отдельная тема — интеграционные решения, в которых может происходить сбои в цепочке, использующей различные компоненты, разработанные двумя, тремя и больше командами. Найти виноватых в этой ситуации крайне сложно, поскольку дефекты чаще всего возникают на стыке интеграционных элементов, из-за выявленных в ходе внедрения несоответствий. И тут важно не искать виновных для наказания, а быстро и конструктивно договориться о совместных уступках разработчиков стыкуемых компонентов, и эффективно решить проблему. Учитывая все вышеперечисленное, этап опытной эксплуатации, чаще всего, насыщен эмоциональными всплесками и взаимными претензиями, как между командами разработчиков, так и с заказчиками. В этом случае очень важна роль архитекторов и системных аналитиков, которые должны оперативно локализовать проблему, предложить ее решение и согласовать его со всеми заинтересованными лицами. Для выполнения подобных работ требуется помимо основных профессиональных навыков, еще и обладание талантом переговорщика, и знанием основ менеджмента. А тем временем мы достигли дна, отведенного для проекта времени… 4. Согласование изменений в процессе внедрения информационной системы Если работа некоторых функциональных модулей информационной системы критически не соответствует потребностям и ожиданиям заказчика, и найдены решения по преодолению этих проблем, то необходимо их зафиксировать и согласовать с заказчиком. Этап согласования нового решения очень важен, как минимум по двум причинам. Во-первых, если объем реализации изменений превысит суммы, заложенные на подобные риски в плане проекта, то необходимо либо заключать дополнительные соглашения, либо команда исполнителей будет работать в убыток. Зачастую исполнителей призывают по- быстрому сделать изменения, а мол учтем их и рассчитаемся за работы по ним потом, одним пакетом. Но по факту же такие случаи, обычно приводят, к тому, что заказчик опосля напрочь забывает свои обещания, а выполненные работы объявляет — исправлением исполнителями своих собственных ошибок. Во-вторых, любые изменения одних компонентов системы могут повлечь за собой неизбежное изменение взаимозависимых компонентов, что требует тщательного анализа и, возможно, перепроектирования целой цепочки подсистем. В противном случае неизбежно возникновение дефектов в работе системы в целом. Проявляться это может например, в отказе работы модуля смежной команды исполнителей, и заказчик уже их объявляет халтурщиками и бракоделами. Правда конечно всплывет, но осадчик останется. И вот перефразируя Ежи Леца: «Когда мы достигли дна отведенного времени, снизу постучались ...» Поскольку время просрочено, необходимо договариваться с заказчиком, и убеждать его, что он в проекте тоже был не подарок, и часть вины лежит именно на нем. 5. Доработка информационной системы по итогам опытной эксплуатации Если в ходе опытной эксплуатации принимаются и согласуются решения о внесении изменений в разработанный программно-аппаратный комплекс, то на основании их выставляются задачи исполнителям по их реализации. Процесс, описанный в разделе Часть 3. Реализация проектного решения повторяется. Но… Если на стадии проектирования системы мы обсуждали отрицательное влияние полномасштабного использования методологии Scrum (1) в больших проектах, то на данном этапе она подходит как нельзя лучше. Особенно это ощутимо в проектах в которых продукт, переданный заказчику, не устраивает его по большей части показателей. Иными словами, пора поддаться панике и очень быстро, «сломя голову» вносить изменения в продукт, который уже эксплуатируют. Очень важно, чтобы в конечном итоге, проектная документация была приведена в полное соответствие с нововведениями, и команда могла легко отыскать в ней актуальное решение для анализа и проектирования последующих изменений. Рисунок 20. – Этап внедрения информационной системы 6. Передача информационной системы в промышленную эксплуатацию Когда в ходе опытной эксплуатации решены все спорные вопросы и недоразумения по поводу того как должна функционировать внедренная система, и насколько она соответствует договору на ее разработку, стороны подписывают акты о выполнении контракта. Заказчик осуществляет полный расчет за выполненные работы. Договор на разработку и внедрение информационной системы может считаться выполненным. Внедрение переходит в фазу промышленной эксплуатации. Эти взаимоотношения чаще всего юридически регулируются уже отдельным договором или дополнительным соглашением на сопровождение промышленной эксплуатацией системы. В рамках этого контракта могут происходить профилактические работы по диагностике работы компонентов системы, их взаимодействия, устранение мелких сбоев и т.п. Контрольные вопросы: Что такое тестирование ИС; Опишите процесс доработки ИС; Какие достоинства и недостатки имеет процесс доработки ИС; Как осуществляется передача в промышленную эксплуатацию. ЛЕКЦИЯ 8 Эксплуатационная документация План. 1. Контрольный опрос 2. Содержание документации 3. Административная документация 4. Пользовательская документация Типы технической документации на программный продукт Всю документацию на программный продукт можно разделить на следующие категории: Документация управления проектом — организационные документы, которыми обмениваются между собой те, кто так или иначе участвует создании программы. Документация разработки — технические документы, которыми обмениваются между собой те, кто так или иначе участвует создании программы. Документация продукции — технические документы, которые предоставляются потребителю в комплекте поставки программы или отдельно от нее. В составе документации продукции можно выделить эксплуатационную документацию, т. е. такую, которая используется при эксплуатации системы. В свою очередь, в составе эксплуатационной документации можно выделить документацию пользователя, адресованную лицам, непосредственно работающим с программой. Состав технической документации на программный продукт Документация разработки программного продукта Состав документации разработки программного продукта в значительной мере зависит от методологии, которую исповедует коллектив разработчиков. Каждая методология, скажем, RUP или MSF, предусматривает свой набор документов. Идеологически эти наборы во многом похожи, хотя одни и те же документы в них могут по-разному называться и иметь разную структуру. В Единой системе программной документации понятие документации разработки отсутствует, но как таковая она там предусмотрена. В табл. 1 приведен состав документации разработки согласно ЕСПД. Таблица 1. Документация разработки программы согласно ЕСПД Документ Источни к Аудитория Содержание техническое задание аналитик проектировщик ПО требования к программе пояснительн ая записка к техническому проекту проектир овщик ПО программист устройство программы программа и методика испытаний аналитик представитель заказчика, осуществляющий приемку программы процедуры, позволяющие убедиться в соответствии программы техническому заданию Эксплуатационная документация на программный продукт Состав комплекта эксплуатационной документации на программный продукт зависит от архитектуры последнего, назначения его компонентов и особенностей пользовательской аудитории. Наиболее распространенные типы эксплуатационных документов приведены в табл. 2. Таблица 2. Эксплуатационная документация на программный продукт Документ Аудитория Примерное содержание описание программы лица, принимающие решения о приобретении, вводе в эксплуатацию и способах использования программы назначение и основные возможности программы, необходимые ей нее системные ресурсы, входные и выходные данные описание применения Документ Аудитория Примерное содержание описание языка пользователи языка (программисты, операторы, кодеры, верстальщики) основная идея языка, его синтаксис, элементы и конструкции, встроенные функции паспорт лица, ответственные за эксплуатацию программы краткие сведения о программе и условиях ее поставки руководство администратора ответственный пользователь системы, обеспечивающий ее целевое применение управление учетными записями пользователей, назначение пользователям прав доступа, ведение нормативно-справочной информации, загрузка и выгрузка данных руководство оператора операторы, работающие с системой, частью которой является программа порядок выполнения предусмотренных операций, сообщения программы и предписанные оператору способы реакции на них руководство пользователя пользователи программы, т.е. лица, применяющие ее для решения собственных прикладных задач назначение и возможности программы, ее основные концепции, интерфейс пользователя, порядок решения типовых задач, описание функций программы руководство программиста программисты, сопровождающие программу или использующие ее в качестве платформы либо средства разработки при создании собственных программ архитектура программы или создаваемых на ее основе приложений, описание программных интерфейсов к ее объектам, протоколов обмена данными и т. п. руководство системного администратора (системного программиста) системные администраторы, осуществляющие установку программы и поддерживающие систему в рабочем состоянии установка программы, ее интеграция в систему, проверка правильности функционирования, устранение аварийных ситуаций спецификация лица, ответственные за эксплуатацию программы комплект поставки программы справочная система («хелп») пользователи, операторы, материал всех имеющихся руководств и Документ Аудитория Примерное содержание администраторы, системные администраторы, программисты и др. описаний, краткие описания элементов интерфейса пользователя программы формуляр лица, ответственные за эксплуатацию программы краткие сведения о программе и условиях ее поставки, записи эксплуатационного о возникающих сбоях и прочих событиях такого рода Контрольные вопросы: Что такое эксплуатационная документация и её функции; Опишите состав эксплуатационной документации; Назовите состав технического задания; Назовите состав пояснительной записки к техническому проекту ; Назовите состав программи и методики испытаний. ЛЕКЦИЯ 9 Совместимость программного обеспечения. План. 1. Контрольный опрос 2. Аппаратная и программная совместимость. 3. Причины возникновения проблем совместимости 4. Методы выявления проблем совместимости ПО Теоретическая часть При переходе с одной операционной системы на другую, перед всеми без исключения организациями встает вопрос совместимости. Совместимость компьютерного парка организации принято делить на 2 части: 1. Аппаратная совместимость. 2. Программная совместимость. В аппаратную совместимость входит соответствие физической составляющей компьютеров требованиям, необходимым для корректной работы операционной системы. Минимальную и рекомендуемую конфигурация компьютера мы разобрали еще в первой лекции. В программную часть входят приложения, используемые конечными пользователями. В какой-то степени к программной части стоит отнести и совместимость драйверов устройств. Ведь если для этой операционной системы нет соответствующих драйверов, то и аппаратная часть работать не будет. Так как драйверы занимают промежуточное положение между программной и аппаратной составляющей компьютера, совместимость этой части программного обеспечения можно отнести как в первую, так и вторую категорию. Основную же проблему совместимости программной части компьютера является совместимость приложений, непосредственно используемых пользователями. Данные приложения могут представлять из себя простые программы, устанавливаемые только на компьютере клиента, или же сложные, типа клиент-серверной архитектуры. Минимальные требования, для работы приложений в той или иной операционной системе перечислены в Windows 7 Software Logo. Дополнительная информация находится на сайте Microsoft https://connect.microsoft.com/site831. Следующие три лекции будут посвящены вопросам совместимости программного и аппаратного обеспечения компьютеров. Первым делом мы разберем возможности утилиты Windows 7 Upgrade Advisor 2.0. Данная утилита достаточно проста в использовании и это ее непосредственный плюс, однако ее функционала не достаточно для тестирования компьютера в организации. На основании этого следующим приложением будет MAP 4.0. Это приложение позволяет анализировать не только клиентские операционные системы и приложения, но и серверные. Основной же упор делается на совместимость с аппаратным обеспечением. Ну и напоследок мы разберем титана сбора сведений о совместимости приложений – ACT 5.6. ACT представляет из себя клиент-серверное приложение и позволяет оценивать совместимость установленных программ не просто по базам совместимости, а анализируя их действия. Тем самым, если в организации используются мало известные или самописные приложения, то данный программный продукт – то, что нужно. К тому же он является бесплатным. Ну и наконец собрав информацию о совместимости приложений мы разберем возможные варианты запуска несовместимых приложений в операционной системе Windows 7. В этом нам помогут две технологии компании Microsoft – Режим совместимости (Compatibility Mode) и Режим Windows XP (Windows XP Mode). Поддержка рабочей среды (совместимость приложений) Проверка приложений на совместимость с новой операционной системой довольно ответственное занятие на этапе планирования развертывания. Не зависимо от того, какие приложения используются в вашей организации, перед началом развертывания необходимо убедиться, что все они совместимы с новой операционной системой. Если какие-либо приложения не совместимы, необходимо получить их обновленные версии, эмулировать работу в другой операционной системе (режим совместимости, Windows XP Mode) или воспользоваться, хотя бы на время, эквивалентами-заменителями. Также есть вариант отказаться от использования несовместимых приложений, но это уже крайний вариант. Производить проверку на совместимость приложений необходимо вне зависимости от того, какая операционная система используется в данный момент на компьютерах пользователей. Многие могут подумать, что операционные системы Windows Vista и Windows 7 полностью совместимы. На самом деле это не совсем так. Хотя Windows 7 и базируется на ядре схожем с ядром Windows Vista (версия 6.0 для Vista против 6.1 для Windows 7) были произведены некоторые изменения. Поэтому при переходе на Windows 7 возможно потребуется обновить некоторые приложения и драйверы до более новой версии или же включить режим совместимости. Контрольные вопросы: Что такое совместимость программного обеспечения; Что такое аппаратная совместимость; Что такое программная совместимость; Как определить совместимо ли ПО с ОС ; Составьте план тестирования ПО на совместимость . |