Тема: Разработка (подготовка) документации и отчетных форм для внедрения программных средств.
Цель: формирование умений составления технической документации программного продукта.
Время выполнения: 2 часа.
Теоретический материал
Тестирование программного обеспечения в процессе внедрения и эксплуатации
Очень часто в больших проектах, тестирование финального релиза не позволяет выявить все проблемные места решения. Причиной тому могут быть: огромные объемы данных на деле в «боевых» условиях, проявление уникальных сочетаний бизнес правил в реальных деловых процессах, особенности работы конкретного оборудования, специфические сочетания компонентов системы, балансирование нагрузки между распределенными узлами и т.п.
Зачастую ситуация еще осложняется тем, что внедрение новых систем на начальных стадиях ни в коей мере не отменяет необходимость производить работы на старых системах. То есть пользователи дублируют данные в обоих системах. Иногда требуется миграция существующих актуальных данных из устаревших хранилищ в новые, а структура и формат информации обычно весьма и весьма отличаются. Например, если в новой структуре данных не хватает информации для заполнения обязательных реквизитов, они заполняются какими-то данными назначенными «по умолчанию», а потом уже корректируются вручную пользователями. И это только малая толика того, с чем приходится сталкиваться в реальных проектах.
Отдельная тема — интеграционные решения, в которых может происходить сбои в цепочке, использующей различные компоненты, разработанные двумя, тремя и больше командами. Найти виноватых в этой ситуации крайне сложно, поскольку дефекты чаще всего возникают на стыке интеграционных элементов, из-за выявленных в ходе внедрения несоответствий. И тут важно не искать виновных для наказания, а быстро и конструктивно договориться о совместных уступках разработчиков стыкуемых компонентов, и эффективно решить проблему.
Согласование изменений в процессе внедрения информационной системы.
Если работа некоторых функциональных модулей информационной системы критически не соответствует потребностям и ожиданиям заказчика, и найдены решения по преодолению этих проблем, то необходимо их зафиксировать и согласовать с заказчиком.
Этап согласования нового решения очень важен, как минимум по двум причинам.
Во-первых, если объем реализации изменений превысит суммы, заложенные на подобные риски в плане проекта, то необходимо либо заключать дополнительные соглашения, либо команда исполнителей будет работать в убыток.
Во-вторых, любые изменения одних компонентов системы могут повлечь за собой неизбежное изменение взаимозависимых компонентов, что требует тщательного анализа и, возможно, перепроектирования целой цепочки подсистем. В противном случае неизбежно возникновение дефектов в работе системы в целом. Проявляться это может, например, в отказе работы модуля смежной команды исполнителей.
Очень важно, чтобы в конечном итоге, проектная документация была приведена в полное соответствие с нововведениями, и команда могла легко отыскать в ней актуальное решение для анализа и проектирования последующих изменений.
Передача информационной системы в промышленную эксплуатацию
Когда в ходе опытной эксплуатации решены все спорные вопросы и недоразумения по поводу того как должна функционировать внедренная система, и насколько она соответствует договору на ее разработку, стороны подписывают акты о выполнении контракта. Заказчик осуществляет полный расчет за выполненные работы. Договор на разработку и внедрение информационной системы может считаться выполненным.
Внедрение переходит в фазу промышленной эксплуатации. Эти взаимоотношения чаще всего юридически регулируются уже отдельным договором или дополнительным соглашением на сопровождение промышленной эксплуатацией системы. В рамках этого контракта могут происходить профилактические работы по диагностике работы компонентов системы, их взаимодействия, устранение мелких сбоев и т.п.
Эксплуатационная документация
Типы технической документации на программный продукт
Всю документацию на программный продукт можно разделить на следующие категории:
Документация управления проектом — организационные документы, которыми обмениваются между собой те, кто так или иначе участвует создании программы.
Документация разработки — технические документы, которыми обмениваются между собой те, кто, так или иначе, участвует в создании программы.
Документация продукции — технические документы, которые предоставляются потребителю в комплекте поставки программы или отдельно от нее.
В составе документации продукции можно выделить эксплуатационную документацию, т. е. такую, которая используется при эксплуатации системы. В свою очередь, в составе эксплуатационной документации можно выделить документацию пользователя, адресованную лицам, непосредственно работающим с программой.
Состав технической документации на программный продукт
Документация разработки программного продукта
Состав документации разработки программного продукта в значительной мере зависит от методологии, которую исповедует коллектив разработчиков. Каждая методология, скажем, RUP или MSF, предусматривает свой набор документов.
Идеологически эти наборы во многом похожи, хотя одни и те же документы в них могут по-разному называться и иметь разную структуру.
В Единой системе программной документации понятие документации разработки отсутствует, но как таковая она там предусмотрена. В табл. 4 приведен состав документации разработки согласно ЕСПД.
Таблица 4
Документация разработки программы согласно ЕСПД
Документ
|
Источник
|
Аудитория
|
Содержание
|
Техническое задание
|
аналитик
|
Проектировщик ПО
|
требования к программе
|
Пояснительная записка к техническому проекту
|
Проектировщик ПО
|
Программист
|
Устройство программы
|
Программа и методика испытаний
|
аналитик
|
Представитель заказчика, осуществляющий приемку программы
|
Процедуры, позволяющие убедиться в соответствии программы к техническому заданию
|
Эксплуатационная документация на программный продукт
Состав комплекта эксплуатационной документации на программный продукт зависит от архитектуры последнего, назначения его компонентов и особенностей пользовательской аудитории. Наиболее распространенные типы эксплуатационных документов приведены в табл. 5.
Таблица 5
Эксплуатационная документация на программный продукт
Документ
|
Аудитория
|
Примерное содержание
|
описание применения
|
лица, принимающие решения о приобретении, вводе в эксплуатацию и способах использования программы
|
назначение и основные возможности программы, необходимые ей нее системные ресурсы, входные и выходные данные
|
описание языка
|
пользователи языка (программисты, операторы, кодеры, верстальщики)
|
основная идея языка, его синтаксис, элементы и конструкции, встроенные функции
|
паспорт
|
лица, ответственные за эксплуатацию программы
|
краткие сведения о программе и условиях ее поставки
|
руководство администратора
|
ответственный пользователь системы, обеспечивающий ее целевое применение
|
управление учетными записями пользователей, назначение пользователям прав доступа, ведение нормативно-справочной информации, загрузка и выгрузка данных
|
руководство оператора
|
операторы, работающие с системой, частью которой является программа
|
порядок выполнения предусмотренных операций, сообщения программы и предписанные оператору способы реакции на них
|
руководство пользователя
|
пользователи программы, т.е. лица, применяющие ее для решения собственных прикладных задач
|
назначение и возможности программы, ее основные концепции, интерфейс пользователя, порядок решения типовых задач, описание функций программы
|
руководство программиста
|
программисты, сопровождающие программу или использующие ее в качестве платформы либо средства разработки при создании собственных программ
|
архитектура программы или создаваемых на ее основе приложений, описание программных интерфейсов к ее объектам, протоколов обмена данными и т. п.
|
руководство системного администратора (системного программиста)
|
системные администраторы, осуществляющие установку программы и поддерживающие систему в рабочем состоянии
|
установка программы, ее интеграция в систему, проверка правильности функционирования, устранение аварийных ситуаций
|
спецификация
|
лица, ответственные за эксплуатацию программы
|
комплект поставки программы
|
справочная система («хелп»)
|
пользователи, операторы, администраторы, системные администраторы, программисты и др
|
материал всех имеющихся руководств и краткие описания элементов интерфейса пользователя программы
|
формуляр
|
лица, ответственные за эксплуатацию программы
|
краткие сведения о программе и условиях ее поставки, записи эксплуатационного о возникающих сбоях и прочих событиях такого рода
|
Состав комплекта эксплуатационной документации на программный продукт зависит от архитектуры последнего, назначения его компонентов и особенностей пользовательской аудитории.
Совместимость программного обеспечения
При переходе с одной операционной системы на другую, перед всеми без исключения организациями встает вопрос совместимости. Совместимость компьютерного парка организации принято делить на 2 части:
1. Аппаратная совместимость.
2. Программная совместимость.
В аппаратную совместимость входит соответствие физической составляющей компьютеров требованиям, необходимым для корректной работы операционной системы.
В программную часть входят приложения, используемые конечными пользователями. В какой-то степени к программной части стоит отнести и совместимость драйверов устройств. Ведь если для этой операционной системы нет соответствующих драйверов, то и аппаратная часть работать не будет. Так как драйверы занимают промежуточное положение между программной и аппаратной составляющей компьютера, совместимость этой части программного обеспечения можно отнести как в первую, так и вторую категорию. Основную же проблему совместимости программной части компьютера является совместимость приложений, непосредственно используемых пользователями. Данные приложения могут представлять из себя простые программы, устанавливаемые только на компьютере клиента, или же сложные, типа клиент-серверной архитектуры. Минимальные требования, для работы приложений в той или иной операционной системе перечислены в Windows 7 Software Logo.
Варианты запуска несовместимых приложений в операционной системе 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 возможно потребуется обновить некоторые приложения и драйверы до более новой версии или же включить режим совместимости.
Виртуализация ОС и её применение
Преимущества виртуализации
Приведем основные достоинства технологий виртуализации:
Эффективное использование вычислительных ресурсов. Вместо 3х, а то 10 серверов, загруженных на 5-20% можно использовать один, используемый на 50-70%. Кроме прочего, это еще и экономия электроэнергии, а также значительное сокращение финансовых вложений: приобретается один высокотехнологичный сервер, выполняющий функции 5-10 серверов. С помощью виртуализации можно достичь значительно более эффективного использования ресурсов, поскольку она обеспечивает объединение стандартных ресурсов инфраструктуры в единый пул и преодолевает ограничения устаревшей модели "одно приложение на сервер".
Сокращение расходов на инфраструктуру. Виртуализация позволяет сократить количество серверов и связанного с ними ИТ-оборудования в информационном центре. В результате этого потребности в обслуживании, электропитании и охлаждении материальных ресурсов сокращаются, и на ИТ затрачивается гораздо меньше средств.
Снижение затрат на программное обеспечение. Некоторые производители программного обеспечения ввели отдельные схемы лицензирования специально для виртуальных сред. Так, например, покупая одну лицензию на Microsoft Windows Server 2008 Enterprise, вы получаете право одновременно её использовать на 1 физическом сервере и 4 виртуальных (в пределах одного сервера), а Windows Server 2008 Datacenter лицензируется только на количество процессоров и может использоваться одновременно на неограниченном количестве виртуальных серверов.
Повышение гибкости и скорости реагирования системы. Виртуализация предлагает новый метод управления ИТ-инфраструктурой и помогает ИТ- администраторам затрачивать меньше времени на выполнение повторяющихся заданий — например, на инициацию, настройку, отслеживание и техническое обслуживание. Многие системные администраторы испытывали неприятности, когда "рушится" сервер. При использовании виртуального сервера — возможен моментальный запуск на любом "железе", а если нет подобного сервера, то можно скачать готовую виртуальную машину с установленным и настроенным сервером, из библиотек, поддерживаемых компаниями разработчиками гипервизоров (программ для виртуализации).
Несовместимые приложения могут работать на одном компьютере. При использовании виртуализации на одном сервере возможна установка linux и windows серверов, шлюзов, баз данных и прочих абсолютно несовместимых в рамках одной не виртуализированной системы приложений.
Повышение доступности приложений и обеспечение непрерывности работы предприятия: Благодаря надежной системе резервного копирования и миграции виртуальных сред целиком без перерывов в обслуживании вы сможете сократить периоды планового простоя и обеспечить быстрое восстановление системы в критических ситуациях. "Падение" одного виртуального сервера не ведет к потере остальных виртуальных серверов. Кроме того, в случае отказа одного физического сервера, возможно, произвести автоматическую замену на резервный сервер. Причем это происходит не заметно для пользователей без перезагрузки. Тем самым обеспечивается непрерывность бизнеса.
Возможности легкой архивации. Поскольку жесткий диск виртуальной машины обычно представляется в виде файла определенного формата, расположенный на каком-либо физическом носителе, виртуализация дает возможность простого копирования этого файла на резервный носитель как средство архивирования и резервного копирования всей виртуальной машины целиком. Возможность поднять из архива сервер полностью еще одна замечательная особенность. А можно поднять сервер из архива, не уничтожая текущий сервер и посмотреть положение дел за прошлый период.
Повышение управляемости инфраструктуры: использование централизованного управления виртуальной инфраструктурой позволяет сократить время на администрирование серверов, обеспечивает балансировку нагрузки и "живую" миграцию виртуальных машин. Виртуальной машиной будем называть программную или аппаратную среду, которая скрывает настоящую реализацию какого-либо процесса или объекта от его видимого представления.
Виртуальная машина — это полностью изолированный программный контейнер, который работает с собственной ОС и приложениями, подобно физическому компьютеру. Виртуальная машина действует так же, как физический компьютер, и содержит собственные виртуальные (т.е. программные) ОЗУ, жесткий диск и сетевой адаптер.
Задания:
1. Разработать устав проекта, по выбранной тематике практического задания №1и согласно требований, предъявляемым к нему (изложены в Таб.6)
Таблица 6
Требования к уставу проекта
№
|
Раздел
|
Пояснения
|
1.
|
Название проекта
|
Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
|
2.
|
Бизнес-причина возникновения проекта
|
Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
|
3.
|
Бизнес-цель
|
Сформулирована заказчиком, исходя из стратегических и тактических целей компании.
|
4.
|
Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта
|
Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
|
5.
|
Расписание основных контрольных событий
|
На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика.
Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта.
Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств.
|
6.
|
Участники проекта
|
Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него.
|
7.
|
Окружение проекта
|
Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор.
Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения)
|
8.
|
Допущения относительно организации и окружения, а также внешние допущения
|
Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
- компетенции команды проекта достаточно для выполнения предпроектного обследования;
-организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта.
Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе
|
9.
|
Ограничения относительно организации и окружения, а также внешние ограничения
|
Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ. Пример ограничений проекта:
увеличение стоимости проекта не более чем на 10%;
- не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.
Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом.
|
10.
|
Объем денежных средств, выделенных на достижение бизнес-цели
|
На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от -20% до +100%
|
11.
|
Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор
|
Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту.
Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и
контроля проекта. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект.
Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении
связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
- утверждать бизнес-цели проекта , включая расписания и бюджет, и вносимые в них изменения;
- назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения;
- формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;
- вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов;
- принимать решения о внесении изменений в базовую линию проекта.
Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта.
Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта.
Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта.
Формировать всю команду и тем более, сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта.
|
2. Изучить теоретический материал и ответить на вопросы.
Контрольные вопросы:
Что такое тестирование ИС?
Опишите процесс доработки ИС.
Какие достоинства и недостатки имеет процесс доработки ИС?
Как осуществляется передача в промышленную эксплуатацию?
Что такое эксплуатационная документация и её функции?
Опишите состав эксплуатационной документации.
Каков состав технического задания?
Назовите состав пояснительной записки к техническому проекту.
Назовите состав программ и методики испытаний.
Что такое совместимость программного обеспечения?
Что такое аппаратная совместимость?
Что такое программная совместимость?
Как определить совместимо ли ПО с ОС?
Составьте план тестирования ПО на совместимость.
Что такое виртуализация сервера?
Что такое виртуальная машина?
Как работает виртуализация?
Каковы преимущества виртуализации?
Рекомендуемая литература: 3 [с. 13 – 40], 4 [с. 15 – 146]
Самостоятельная работа №1
Тема: Сценарии внедрения программного продукта для рабочего места.
Цель: формирование умений разрабатывать сценария внедрения программного продукта для рабочего места.
Время выполнения: 2 часа.
Форма отчетности: мультимедийная презентация.
Задание: изучить теоретический материал по данной теме и разработать презентацию по теме "Сценарии внедрения программного продукта для рабочего места"
Рекомендуемая литература: 2 [с. 10 – 22], 3 [с. 40 – 77].
Самостоятельная работа №2
Тема: Выявление и документирование проблем установки программного обеспечения.
Цель: формирование умений выявлять и документировать проблемы установки программного обеспечения.
Время выполнения: 2 часа.
Форма отчетности: реферат.
Задание: изучить теоретический материал по данной теме и выполнить реферат по указанной теме.
Рекомендуемая литература: 2 [с. 77 – 101], 3 [с. 146 – 247].
Самостоятельная работа №3
Тема: Устранение проблем совместимости программного обеспечения.
Цель: формирование умений устранять проблемы совместимости программного обеспечения.
Время выполнения: 2 часа.
Форма отчетности: реферат.
Задание: изучить теоретический материал по данной теме и выполнить реферат по указанной теме.
Рекомендуемая литература: 3 [с. 13 – 40], 4 [с. 15 – 146]
Самостоятельная работа №4
Тема: Конфигурирование программных и аппаратных средств.
Цель: формирование умений конфигурации программных и аппаратных средств.
Время выполнения: 4 часа.
Форма отчетности: реферат.
Задание: изучить теоретический материал по данной теме и выполнить реферат по указанной теме.
Рекомендуемая литература: 1 [с. 85 – 96]. , 3 [с. 146 – 247].
СПИСОК ЛИТЕРАТУРЫ
Колкова, Н. И. Информационное обеспечение автоматизированных библиотечно-информационных систем (АБИС): учебник для вузов / Н. И. Колкова, И. Л. Скипор. — 2-е изд. — Москва: Издательство Юрайт, 2020. — 355 с. — (Высшее образование). — ISBN 978-5-534-11098-2. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/456713
Нетёсова, О. Ю. Информационные системы и технологии в экономике: учебное пособие для вузов / О. Ю. Нетёсова. — 3-е изд.,испр. и доп. — Москва : Издательство Юрайт, 2020. — 178 с. — (Высшее образование). — ISBN 978-5-534-08223-4. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/452595
Разработка модулей программного обеспечения для компьютерных систем [Текст]: учебник / Г. Н. Федорова. - 2-e изд., стер. - Москва: Академия, 2018. - 384 с.: ил. - (Топ 50) (Профессиональное образование). - Библиогр: с. 378-379
Соколова, В. В. Вычислительная техника и информационные технологии. Разработка мобильных приложений: учебное пособие для вузов / В. В. Соколова. — Москва: Издательство Юрайт, 2020. —175 с. — (Высшее образование). — ISBN 978-5-9916-6525-4. —Текст: электронный // ЭБС Юрайт [сайт]. — URL:https://urait.ru/bcode/451366
Учебное издание
МДК.03.01 ВНЕДРЕНИЕ И ПОДДЕРЖКА КОМПЬЮТЕРНЫХ СИСТЕМ
Методические указания по практическим занятиям
и по организации самостоятельным работам
Составитель
ПРОДАНЧУК Игорь Витальевич
Ответственный редактор
Н.В. Кравченко, председатель ЦК ИТ СОНХ
В авторской редакции
Подписано в печать . Формат 60х90 1/16. Усл. печ. л. 3,0.
Тираж 10 экз. Заказ № .
Библиотечно-издательский комплекс
федерального государственного бюджетного образовательного
учреждения высшего образования
«Тюменский индустриальный университет».
625000, Тюмень, ул. Володарского, 38.
Типография библиотечно-издательского комплекса.
6 25039, Тюмень, ул. Киевская, 52.
2
|
Скачать 0.65 Mb.