Внедрение и поддержка компьютерных систем

1.

МДК 04.01 Внедрение и
поддержка компьютерных
систем
Преподаватель – Ильин Алексей Андреевич

2.

КРАСТКОЕ ОПИСАНИЕ
ДИСЦИПЛИНЫ
Место дисциплины в структуре
основной
профессиональной
образовательной
программы:
дисциплина МДК 04.01 «Внедрение и
поддержка компьютерных систем»
входит в ПМ.04 Сопровождение и
обслуживание
программного
обеспечения компьютерных систем.

3.

Цель и планируемые результаты
освоения дисциплины
Иметь
В настройке отдельных компонентов программного обеспечения компьютерных
практически систем; выполнении отдельных видов работ на этапе поддержки программного
й опыт
обеспечения компьютерной системы
уметь
подбирать и настраивать конфигурацию программного обеспечения компьютерных
систем; использовать методы защиты программного обеспечения компьютерных
систем; проводить инсталляцию программного обеспечения компьютерных систем;
производить настройку отдельных компонентов программного обеспечения
компьютерных систем; анализировать риски и характеристики качества
программного обеспечения
знать
основные методы и средства эффективного анализа функционирования
программного обеспечения; основные виды работ на этапе сопровождения
программного обеспечения; основные принципы контроля конфигурации и
поддержки целостности конфигурации программного обеспечения; средства защиты
программного обеспечения в компьютерных системах

4.

Темы дисциплины «Основы
проектирования баз данных»
Раздел 1. Основные методы внедрения и анализа
функционирования программного обеспечения
Раздел 2. Загрузка и установка программного обеспечения

5.

Тема 1. ГОСТ Р ИСО/МЭК
12207. Основные процессы
и взаимосвязь между
документами в
информационной системе
согласно стандартам

6.

Основные вопрос темы:
1. Основные понятия
2. Стандарты внедрения ПО
3. Процессы, регламентируемые ГОСТ Р ИСО/МЭК 12207—
2010

7.

Основные понятия
Программным обеспечением (ПО), или software, принято
называть набор команд, управляющих работой компьютера.
ГОСТ Р 51904—2002 «Программное обеспечение встроенных
систем. Общие требования к разработке
и документированию» определяет программную систему
как «систему, состоящую из программного обеспечения и,
возможно, компьютерного оборудования для его
выполнения»

8.

Основные понятия
В общей иерархии ПО, состоящего из различных программных
комплексов, ГОСТ Р МЭК 61508-4—2012 определяет
программный модуль как «конструкцию (часть компьютерной
программы — прим. авт.), которая состоит из процедур
и (или) объявлений данных и которая может
взаимодействовать с другими подобными конструкциями».
Проще говоря, программный модуль — это тот «кирпич», из
которого строится все здание под названием программное
обеспечение. В свою очередь, упомянутый ранее
программный комплекс (ПК) представляет
собой совокупность программных модулей, предназначенных
для решения одной задачи и составляющих одно целое.

9.

Заказчику разработчик ПО передает программный
продукт, представляющий собой программный комплекс
(комплексы) вместе с соответствующей документацией,
регламентирующей правила обращения с ним персонала
предприятия-заказчика.

10.

Процесс разработки типового программного продукта
включает в себя этап анализа требований к программному
продукту, этапы его проектирования, реализации
и тестирования, а также этапы внедрения и поддержки.
Указанными этапами не ограничивается так называемый
жизненный цикл (ЖЦ) программного продукта.
Названный цикл — это период времени с момента принятия
решения о необходимости создания программного продукта
до момента его полного изъятия из эксплуатации. В более
общем смысле описание ЖЦ ПО — это описание процесса
его построения и развития.

11.

Современные программные продукты отличаются высокой
сложностью, поэтому для упрощения и стандартизации
этапов их разработки используются специальные стандарты.

12.

К стандартам, регламентирующим организацию процессов
ЖЦ ПО, относятся:
ГОСТ 34.601—90 «Информационная технология. Комплекс
стандартов на автоматизированные системы.
Автоматизированные системы. Стадии создания»
ГОСТ Р ИСО/МЭК 12207—2010 «Информационная технология.
Процессы жизненного цикла программных средств» (ISO/IEC
12207—2008). Федеральным агентством по техническому
регулированию и метрологии 1 марта 2012 г. взамен ГОСТ Р
ИСО/МЭК 12207—99 принят стандарт ГОСТ Р ИСО/МЭК 12207—
2010 «Информационная технология. Системная и программная
инженерия. Процессы жизненного цикла программных средств»,
идентичный международному стандарту ISO/IEC 12207—2008
«System and software engineering — Software life cycle processes».

13.

Стандарт ГОСТ Р ИСО/МЭК 12207—2010 является основным
нормативным документом, регламентирующим состав
процессов ЖЦ ПО. Он определяет структуру ЖЦ,
содержащую процессы действия и задачи, которые должны
быть выполнены во время создания ПО. Каждый процесс
разделен на набор действий, каждое действие — на набор
задач. Каждый процесс, действие или задача инициируется
и выполняется другим процессом по мере необходимости,
причем не существует заранее определенных
последовательностей выполнения. Связи по входным
данным при этом сохраняются.

14.

ГОСТ Р ИСО/МЭК 12207—2010 не предлагает конкретную
модель ЖЦ, т. е. структуру, определяющую
последовательность выполнения и взаимосвязи процессов,
действий и задач. Положения стандарта являются общими
для любых моделей ЖЦ, методов и технологий создания ПО.
Он описывает структуру процессов ЖЦ, не конкретизируя, как
реализовать или выполнить действия и задачи, включенные
в эти процессы.

15.

Назначение стандарта ГОСТ Р ИСО/МЭК 12207—2010.
Устанавливая общую структуру процессов ЖЦ ПО, на
которую можно ориентироваться в программной индустрии,
стандарт определяет процессы, работы и задачи, которые
используются:
• при приобретении (заказ-поставка) программных средств;
• оказании программной услуги;
• разработке, эксплуатации и сопровождении программных
средств.

16.

Процессы, регламентируемые ГОСТ Р ИСО/МЭК 12207—
2010. Данные процессы подразделяют на следующие группы:
основные, вспомогательные и организационные.

17.

Основные процессы относятся непосредственно к ЖЦ
информационной системы и являются, по сути,
производственными процессами организации. К основным
относятся процессы приобретения, поставки, разработки,
эксплуатации и сопровождения ПО. Процессы приобретения
и поставки ПО — это строго регламентированное взаимодействие
«заказчик—поставщик». Разработка ПО включает в себя
следующие этапы, выполняемые разработчиком: создание ПО,
оформление проектной и эксплуатационной документации,
подготовка тестовых и учебных материалов и ряд других. Задачи
эксплуатации и сопровождения ПО решаются соответственно
оператором и службой сопровождения организации,
эксплуатирующей программный продукт. Собственно под
сопровождением ПО понимается процесс внесения в него
изменений для исправления ошибок, для повышения
производительности и (или) адаптации к изменившимся условиям
работы или требованиям.

18.

Вспомогательные процессы предназначены
для поддержки основных процессов. Данные процессы
необходимы организации для поддержания высокого
качества основных процессов, которые они обслуживают.
К вспомогательным относятся следующие процессы:
• документирование;
• управление конфигурацией;
• обеспечение качества;
• аттестация и верификация ПО;
• совместная оценка состояния работ по проекту;
• аудит и разрешение выявленных проблем.

19.

• Под документированием понимается формализованное
описание информации, созданной в течение всего ЖЦ ПО.
• Управление конфигурацией представляет собой комплекс
административных и технических процедур, реализуемых
на всем протяжении ЖЦ ПО. К задачам данного процесса
относятся определение состояния компонентов ПО
и управление его модификациями. Содержанием процессов
обеспечения качества является поддержание параметров
ПО в рамках заданных требований.
• Целью тесно связанных между собой вспомогательных
процессов аттестации и верификации является проверка
полноты соответствия параметров ПО их конкретному
функциональному назначению после и (или) в процессе
влияния на ПО внешних факторов (восстановление после
сбоев, повторная установка с дистрибутива и др.).

20.

• Совместная оценка состояния работ по проекту
необходима для контроля процессов планирования
и управления ресурсами организации, персоналом,
аппаратурой, инструментальными средствами. По
результатам проведенной оценки составляются акты по
восстановлению ненадежных ресурсов.
• Разрешение проблем, выявленных при аудите (проверке
соответствия ПО условиям договора), включает в себя
мероприятия по восстановлению нормальной работы ПО
при его некорректной работе (из-за вирусов, старения
носителей и др.) на любом этапе ЖЦ.

21.

Организационные процессы — это процессы,
затрагивающие весь персонал предприятия и происходящие
независимо от того, как организовано производство и как
устроены вспомогательные процессы.
К организационным относятся процессы управления,
обучения, создания и усовершенствования инфраструктуры
ПО.

22.

Процессы управления связаны с набором мероприятий по
бесперебойному функционированию основных
и вспомогательных процессов в организации. На
предприятии кроме первоначального обучения персонала
обычно периодически проводятся мероприятия по
повышению его квалификации. Содержанием процессов по
созданию и усовершенствованию программной
инфраструктуры является сопровождение технологии
и стандартов, выбор и установка аппаратных и ПО,
используемых для разработки, эксплуатации и (или)
сопровождения ПО, а также периодический контроль его
состояния.

23.

Структура процессов ЖЦ ПО по
ГОСТ Р ИСО/МЭК 12207—2010

24.

Процесс заказа ПО (блок 5.1) состоит из работ и задач,
выполняемых заказчиком, и начинается с определения его
потребностей в программной системе, программном
продукте или программной услуге. Далее следуют подготовка
и выпуск заявки на подряд, выбор поставщика и управление
процессом заказа вплоть до завершения его приемки.
Конкретная организация, имеющая соответствующую
потребность, может быть названа собственником, который
заключает договор на выполнение части или всех работ по
заказу с посредником. Последний далее проводит работы
в соответствии с процессом заказа. В данном подразделе под
заказчиком понимается собственник или посредник.

25.

Процесс обеспечения качества (блок 6.3) реализует
общие принципы управления качеством. Общие принципы
состоят в том, что, во-первых, должен быть разработан
и выполнен план работ и задач процесса обеспечения
качества. Во-вторых, должны быть выполнены работы по
обеспечению качества продукта (т. е. программной системы)
всех задействованных процессов и системы качества (если
это предусмотрено договором). Перечисленные в стандарте
работы по обеспечению качества продукта и процессов
направлены на то, чтобы обеспечить соответствие продукта
и процессов требованиям, сформулированным в договоре,
установленных стандартах и процедурах. Сюда же входят
и требования к квалификации персонала.

26.

Процесс верификации (блок 6.4) стандарта обеспечивает
условие функционирования ПО в полном соответствии
с требованиями. Он объединяет все работы по анализу
составных частей ПО и ПО в целом, включая процессы,
выбранные для реализации проекта в результате адаптации.
Для каждого из объектов (проекта, договора, собственно
программы, сборке) стандарт приводит набор критериев
для анализа. Например, для анализа процессов
используются следующие критерии соответствия:
• проектных требований срокам реализации;
• возможности реализации проекта условиями договора;
• применимости стандартов процессам проектирования;
• состава и квалификации персонала условиям договора.

27.

Процесс аттестации (блок 6.5) представляет собой
процесс определения полноты соответствия ПО его
функциональному назначению. Для выполнения этого
процесса можно привлекать независимого исполнителя,
который подготовит контрольные примеры, тестовые данные,
специально отобранных пользователей для испытаний
системы. Разница между верификацией ПО и его
аттестацией состоит в том, что верификация, в частности,
обеспечивает соответствие ПО стандартам
программирования и требованиям устойчивости к ошибкам,
а аттестация — регламентирует деятельность по
тестированию ПО.

28.

Процесс совместного анализа (блок 6.6) включает в себя
две стороны, участвующие в договоре: анализирующую
и анализируемую. Анализируются управление проектом
и технические объекты, т. е. создаваемое ПО и услуги.
В стандарте приводится шесть характеристик ПО, которые
необходимо анализировать: мобильность, надежность,
эффективность, учет человеческого фактора,
модифицируемость, коммуникативность. Анализ
выполняется периодически в сроки, установленные
проектным планом.

29.

Процесс аудита (блок 6.7) является процессом
определения соответствия ПО требованиям, планам
и условиям договора. Аудит может выполняться двумя
любыми сторонами, участвующими в договоре, и обычно
проводится в сроки, установленные планом проекта.
Критерии завершения, взаимные обязательства и результаты
согласуются сторонами. Основными целями аудита являются
проверки соответствия программных продуктов проектной
документации, тестовых данных установленным техническим
требованиям, а также проверки соответствия завершенности
тестирования отсутствию замеченных, но не устраненных
ошибок.

30.

Лекция 2. Виды внедрения,
план внедрения. Стратегии,
цели и сценарии внедрения.
Функции менеджера
сопровождения и менеджера
развертывания

31.

План:
1. Виды внедрения, план внедрения
2. Стратегии, цели и сценарии внедрения
3. Функции менеджера сопровождения и
менеджера развертывания

32.

Виды внедрения, план
внедрения
Внедрение программного обеспечения —
процесс настройки программного обеспечения
под определённые условия использования, а
также обучения пользователей работе с
программным продуктом

33.

Внедрение программного обеспечения требует
действий в трёх следующих плоскостях работ:
• Выделение критических, с точки зрения общего
результата, процедур в деятельности организации.
• Расширение нормативной базы организации путём
включения в неё регламентов, описывающих
порядок выполнения процедур автоматизируемых
процессов.
• Выполнение работ по общей стандартизации
существующей деятельности организации.

34.

В зависимости от потребностей Заказчика,
автоматизацию учета на предприятии возможно
осуществить 3 методами:
• Обычная установка программного
обеспечения;
• Стандартное внедрение;
• Проектное внедрение.

35.

Проектное внедрение состоит из следующих
этапов:
• обследование;
• проектирование;
• разработка;
• внедрение и опытная эксплуатация.

36.

Стратегии и сценарии внедрения
программного обеспечения
Целью опытных внедрений является
апробация и демонстрация работоспособности
технологии. Активную роль в опытном
внедрении
играют
разработчики
ПО,
а организация, в которой внедрение проходит,
часто довольно пассивна.

37.

Целью масштабных внедрений является
проверка
масштабируемости
технологии
и возможности ее использования в крупных
проектах в контексте реального производства.
Хотя разработчики ПО играют здесь важную
роль, но основную часть работы берет на себя
персонал организации, в процессы которой
новая технология должна вписаться, иначе
внедрение окажется просто невозможным.

38.

Конвейерные внедрения происходят в рамках
уже отработанного специализированного процесса
внедрения, вовлекающего персонал как внедряющей
организации, так и той, в которой осуществляется
внедрение, и четко определяющего все процедуры,
входные данные и результаты каждого шага и роли
вовлеченных лиц. Проводятся такие внедрения
силами
специализированных
организацийпосредников и чаще всего не задействуют
разработчиков технологии.

39.

Основными этапы внедрения программного
продукта являются:
1. обследование;
2. разработка технического задания;
3. настройка системы (программного продукта);
4. тестирование системы;
5. опытная эксплуатация;
6. промышленная эксплуатация.

40.

Под
обследованием
понимается
диагностика
на
предприятии всех бизнес-процессов, которые будет охватывать
будущая система. Количество дней для обследования может
быть разным в зависимости от масштаба и функциональности
создаваемой системы на основе выбранного программного
продукта. Если автоматизируются большое количество
филиалов и программный продукт охватывает большое
количество пользователей или большое количество бизнеспроцессов, то время, отведенное на обследование, будет
существенно увеличено.
Обычно на обследование отводится от одной недели до
одного
месяца
(средняя
продолжительность
этапа
«обследование» — две недели).

41.

Разработка технического задания включает
в себя описание справочников системы, алгоритмов
расчета,
отчетных
форм,
автоматизированных
рабочих
мест
пользователей
и
описание
разграничения
прав
доступа
пользователей.
Разработка технического задания занимает от одного
до трех месяцев.

42.

Настройка системы предусматривает формирование
в программе описаний, перечисленных в разделе
«Разработка технического задания». Продолжительность
этапа напрямую зависит от квалификации специалистов и от
уровня сложности поставленной задачи и составляет от
одного до полутора месяцев.
Тестирование системы предполагает подготовку
демонстрационного примера, внесение тестовых данных,
проверку алгоритмов расчета и исправление обнаруженных
ошибок. В среднем на этап тестирования отводится две
недели.

43.

Опытная эксплуатация ПО подразумевает работу ПО
с реальными данными и необходима для того, чтобы можно
было сопоставить результаты работы в новой системе
с результатами, которые были получены прежним способом.
Этап опытной эксплуатации занимает около одного месяца.
После окончания всех работ внедрение ПО считается
завершенным и начинается его эксплуатация. Однако часто
в начале этапа эксплуатации приходится производить работы
по доработке системы и исправлению найденных ошибок.
Промышленная эксплуатация системы включает
в себя переход предприятия на новое ПО с одновременным
отказом
от
всех
альтернативных
ПО,
при
этом
модернизируются службы технической поддержки. Данный
этап обычно занимает около одного месяца.

44.

При подготовке плана для проекта внедрения ПО
следует:
1) оценить различные методы внедрения: быстрый,
предварительно конфигурированный, поэтапный,
метод «большого скачка», реинжиниринг (т. е.
переосмысление
и
радикальное
перепроектирование),
метод
на
основе
координационного центра, объединяющего всех
участников;
2) определить структуру проекта внедрения,
включающую в себя команду проекта, его
организационный комитет и менеджера проекта;

45.

3) создать рабочий план, определить приблизительное
время процесса внедрения, подлежащее уточнению по
результатам анализа, от эффективности которого зависит
окончательный бюджет проекта внедрения;
4) определить и задокументировать все предложения,
которые были сделаны в самом начале проекта внедрения;
5) создать рабочий документ с оценкой факторов риска
и спланировать методы их устранения;
6) документировать все, что осталось за рамками проекта
внедрения.

46.

Под сценариями внедрения ПО понимается комплекс
действий и задач, выполняемых и решаемых заказчиком,
приобретающим ПО.
Последовательность
шагов
типового
сценария
подразумевает:
1) подготовку заявки на приобретения ПО;
2) подготовку договора на приобретение ПО;
3) контроль за деятельностью поставщика;
4) составление актов приемки работ.

47.

Работа
поставщика
находится
под
постоянным контролем,
который
регламентирован
положениями стандарта
ИСО/МЭК 12207 —2010
и проводится в рамках
процесса
совместной
оценки и аудита.
На рис. 1.2 и 1.3
показаны соответственно
один
из
возможных
сценариев планирования
проекта ПО и основные
этапы его разработки.
Рис. 1.2. Сценарий
планирования проекта

48.

Рис. 1.3. Процесс разработки ПО

49.

На этапе подготовительной работы с учетом
сложности проекта выбирается модель ЖЦ ПО
и в соответствии с ней определяются задачи
процесса разработки ПО и действия по их решению.
При составлении плана работ на этом этапе
разработчик использует те стандарты, методы
и средства, которые согласованы с заказчиком.

50.

На этапе анализа требований, предъявляемых к ПО
с
учетом
критериев
реализуемости,
определяются
функциональные
возможности
ПО
и
основные
предъявляемые
к
нему
требования
(надежность,
безопасность,
интерфейсы
и
др.),
обеспечивается
возможность проверки при тестировании.
На
этапе
проектирования
архитектуры
ПО
определяются его основные компоненты (например,
аппаратура, базовый транслятор), а также оговаривается
состав и функции персонала, обслуживающего ПО.
Параметры каждого компонента ПО здесь согласуются
с параметрами всей архитектуры проекта, причем
обязательно учитываются требования ГОСТ Р ИСО/МЭК
12207—2010.

51.

Анализ требований к ПО является содержанием следующего
этапа разработки, на котором определяются характеристики
каждого его компонента, показанные на рис. 1.4.

52.

На этапе детального проектирования
архитектуры компоненты ПО согласуются по
уровням архитектуры и документируются,
интерфейсы компонентов согласуются друг
с другом и с форматами базы (баз) данных
проекта.

53.

• На этапе кодирования и тестирования ПО решаются
задачи составления тестовых процедур и тестовых данных
для проверки ПО и реализуется собственно процедура
тестирования. По завершении тестирования ПО
выполняется коррекция документации, обновляется план по
интеграции ПО в общую архитектуру проекта, т. е.
подготавливаются условия для проведения следующего
этапа — этапа интеграции, на котором отлаженные
компоненты собираются в единый ПК.

54.

На этапе кодирования и тестирования ПО решаются
задачи составления тестовых процедур и тестовых данных
для проверки ПО и реализуется собственно процедура
тестирования. По завершении тестирования ПО выполняется
коррекция документации, обновляется план по интеграции
ПО в общую архитектуру проекта, т. е. подготавливаются
условия для проведения следующего этапа — этапа
интеграции,
на
котором
отлаженные
компоненты
собираются в единый ПК.

55.

На следующем этапе — этапе квалификационного
тестирования — для каждого включенного в ПК
компонента подготавливаются наборы тестовых процедур,
успешное выполнение которых (обычно, в присутствии
заказчика) гарантирует работоспособность компонента
в составе ПК в заданных условиях эксплуатации.
Квалификационное тестирование каждого компонента
проводится в широком диапазоне варьирования параметров
тестов. Данные тестирования проверяются на полноту их
соответствия параметрам пользовательской документации.

56.

На этапе интеграции компоненты ПО и реальное
оборудование,
на
котором
оно
будет
функционировать, собираются в единый программноаппаратный комплекс, и полученная таким образом
информационная
система
снова
подвергается
квалификационному тестированию как единая
система. При совпадении результатов тестирования
с
техническими
требованиями
производится
окончательное оформление документации на готовый
проект.

57.

Установка и приемка ПО, выполняемые его
разработчиком, проводятся в соответствии с планом
приемки на территории и оборудовании заказчика. На
этих этапах проверяется работоспособность ПК,
документируются и оцениваются результаты его
квалификационного тестирования.

58.

Эксплуатационное тестирование проводится в рабочей
среде (допускается симулированная среда), причем особое
внимание сосредоточивается на функциональных аспектах
ПО. Проверяется восстанавливаемость системы при сбоях,
поведение ресурсов, устанавливаемость ПО на заявленном
оборудовании и техническое соответствие ПО оборудованию,
на котором оно функционирует.
Завершается передача ПК заказчику оговоренными
в договоре процессами обучения персонала и поддержки.
Процесс собственно эксплуатации ПО требует от
оператора выполнения всех пунктов эксплуатационного
стандарта для конкретного оборудования.

59.

Функции менеджера
сопровождения и менеджера
развертывания
Менеджер сопровождения – это сотрудник, который
замыкает на себе основные функции работы с клиентом и
оказывает ему поддержку – от момента первого визита и
взаимодействия с администратором и на протяжении всего
периода использования клиентом услуг салона или центра.
Менеджер сопровождения старается как можно дольше
продлить сотрудничество своей компании с клиентом,
постоянно расширяя и углубляя диапазон услуг.

60.

Типовые функции
инструментария для
автоматизации
процесса внедрения
информационной
системы

61.

План:
1. Сопровождение и развертывание программного
обеспечения
2. Автоматизированные средства разработки программного
обеспечения

62.

Сопровождение и развертывание
программного обеспечения

63.

Сопровождение ПО — это процесс изменения программной
системы после ее поставки заказчику.
На этом этапе исправляются незначительные ошибки
программирования и (или) корректируются отдельные
недоработки, не связанные с изменением общей
архитектуры системы. При этом либо изменяются
существующие, либо добавляются новые компоненты ПО.

64.

Сопровождение в целях исправления ошибок
(корректирующее сопровождение) выполняется в случае
появления в ПО ошибок в программировании, либо ошибок
проектирования, либо ошибок в системных требованиях.
Первые — достаточно легко устранимые ошибки.
Исправления ошибок проектирования обходятся весьма
дорого, поскольку требуют корректировки и (или)
перепрограммирования отдельных компонентов. Ошибки
в системных требованиях требуют перепроектирования всей
системы и поэтому являются самыми дорогостоящими.

65.

• Сопровождение в целях адаптации ПО к условиям
эксплуатации (адаптивное сопровождение) выполняется
при изменении оговоренных в техническом задании условий
и заключается в дополнительной модификации ПО.
• Сопровождение в целях изменения функциональных
возможностей системы проводится, например, для
поддержки аппаратных средств, операционной системы
(ОС) и (или) ПО. Расширение функциональных
возможностей системы, как правило, облегчает работу
с ней оператора и облегчает ее адаптацию к новому
рабочему окружению.

66.

• Согласно исследованиям 65% сопровождения связано
с выполнением новых требований, 18% — отводится на
изменения системы в целях адаптации к новому окружению
и 17% — связано с исправлением ошибок.

67.

Из диаграммы следует, что типы исправление ошибок
и адаптация не относятся к наиболее распространенным
типам, а наиболее востребованной категорией
сопровождения является расширение функциональных
возможностей системы или ее модификация. Отсюда
непосредственно следует, что спиральная модель процесса
развития ПО, предпочтительней каскадной модели,
рассматривающей сопровождение как самостоятельный
процесс.

68.

69.

Исследования показали, что использование ПО
в организации стоит на втором месте по затратам, уступая
первое место именно сопровождению, причем половину
средств, отпущенных организацией на программирование,
забирает статья «Развитие уже существующих систем»,
и около трети из них расходуется на сопровождение.

70.

Содержание процессов сопровождения зависит от типа ПО,
технологии его разработки, уровня специалистов, которые
непосредственно вовлечены в процесс, и некоторых других
факторов. Однако в общем случае можно выделить
совпадающие факторы и этапы в этих процессах, а именно:
• анализ изменений;
• планирование новой версии ПО;
• реализация новой версии системы;
• поставка системы заказчику.

71.

При поступлении заказа на модернизацию ПО определяются
уровень и стоимость внедрения модернизации системы.
Сразу за положительным решением следует этап
планирования новой версии системы, в процессе которого
определяется тип модернизации: исправление ошибок,
адаптация или расширение функциональных возможностей
системы. После выбора того или иного типа выполняется
собственно модернизация ПО и выходит новая версия
системы

72.

73.

Процесс модернизации сопровождается изменением параметров
системы, архитектуры и собственно ПО, в которое добавляются новые
компоненты. После внесенных изменений выполняется повторное
тестирование ПО и проводится подробный анализ изменений,
при котором могут выявиться те последствия модернизации, которые
не были замечены при начальном анализе изменений

74.

Развертывание ПО является частью ЖЦ ПО
и подразумевает все действия, которые делают программную
систему готовой к использованию. Ряд специалистов
трактуют термин «развертывание» как общий процесс,
соответствующий определенным требованиям
и характеристикам. Развертывание может осуществляться
в процессе разработки ПО самим программистом.

75.

Автоматизированные средства
разработки программного
обеспечения

76.

Автоматизированные средства разработки ПО — это
специальный тип ПО, предназначенного для поддержки процессов создания самих программных средств, таких как разработка требований к ПО, проектирование ПО, кодирование
и тестирование программ и т. д.
Понятие автоматизированных средств разработки ПО эквивалентно понятию Computer-Aided Software Engineering
(CASE), под которым понимается набор инструментов и методов программной инженерии для проектирования ПО
и (или) информационных систем. Технология CASE помогает
обеспечить высокое качество программ, простоту их обслуживания и отсутствие ошибок.

77.

• Технология CASE предлагает поддержку процесса создания
ПО путем автоматизации подавляющего большинства этапов его разработки. Примеры CASE-процессов, или (что то
же) процессов, которые можно автоматизировать с помощью CASE-средств

78.

79.

Список ключевых понятий, которыми оперирует индустрия
CASE-средств, приведен далее.
Процесс создания ПО — это совокупность процессов, выполняемых при его разработке.
Модели процесса создания ПО — абстрактные представления этих процессов. Любой процесс создания ПО включает
в себя этапы разработки системной спецификации, проектирования и реализации, аттестации и модернизации ПО.
Обобщенные модели создания ПО описывают организацию процесса разработки программных систем. К таким моделям относятся каскадная модель, эволюционная модель
разработки, модель формальной разработки систем и модель разработки ПО на основе ранее созданных компонентов.

80.

Итерационные модели разработки ПО представляют собой процесс создания программных систем в виде повторяющихся циклов определенных этапов разработки. Достоинством данного подхода является возможность избежать преждевременного и до конца не продуманного утверждения системной спецификации и результатов проектирования. Примерами итерационных моделей служат модель пошаговой
разработки и спиральная модель.
Определение требований — это процесс разработки системной спецификации

81.

Проектирование и реализация — это процессы преобразования системной спецификации в систему исполняемых
программ.
Аттестация ПО — это процесс проверки соответствия разработанной системы ее спецификации и потребностям
пользователей.
Эволюция ПО — это модернизация существующих программных систем в соответствии с новыми требованиями.

82.

Однако, несмотря на все потенциальные возможности CASEсредств, существует множество примеров их неудачного
внедрения, в результате которых CASE-средства становятся
невостребованными. В связи с этим отметим следующее:
• CASE-средства необязательно дают немедленный эффект — он может быть получен только спустя какое-то время;
• реальные затраты на внедрение CASE-средств обычно
намного превышают затраты на их приобретение;
• CASE-средства обеспечивают возможности для получения
существенной выгоды только после успешного завершения
процесса их внедрения.

83.

Оценка качества функционирования
информационной системы. CALSтехнологии. Организация процесса
обновления в информационной системе.
Регламенты обновления

84.

• Функциональность — способность ПО решать задачи, которые соответствуют зафиксированным и предполагаемым
потребностям пользователя при заданных условиях использования ПО. Эта характеристика отвечает за то, что ПО
работает исправно и точно, функционально совместимо, соответствует стандартам отрасли и защищено от несанкционированного доступа.

85.

• Надежность — способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного
промежутка времени или указанное количество операций.
Атрибуты данной характеристики — это завершенность
и целостность всей системы, способность самостоятельно
и корректно восстанавливаться после сбоев в работе, отказоустойчивость.

86.

• Удобство использования — возможность комфортного
изучения ПО пользователем.
• Эффективность — способность ПО обеспечивать требуемый уровень производительности в соответствии с выделенными ресурсами, временем и другими обозначенными
условиями.
• Удобство сопровождения — легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований,
для облегчения дальнейшего обслуживания и адаптироваться к имеющемуся окружению.
• Портативность — характеризует ПО с точки зрения мобильности его переноса из одного окружения в другое.

87.

88.

Виды деятельности, охватываемые моделью обеспечения качества ISO 9001
Вид деятельности менеджмента
Элемент системы качества
Выявление бракованных изделий
Контроль за разработкой изделий
Обработка, хранение, упаковка и дос- Материально-техническое обслуживатавка товара
ние
Товары, поставляемые заказчиком
Идентификация и отслеживание товара
Управление производственным про- Контроль и испытания готовой продукцессом
ции
Оборудование для контроля и испы- Проведение обследования и тестироватаний
ния
Проверка контракта
Корректирующая деятельность
Проверка документации
Отчеты об обеспечении качества
Внутренняя проверка качества
Обучение
Статистические методы контроля за каОбслуживание
чеством

89.

90.

91.

Управление качеством ПО включает в себя следующие
процессы:
1) определение стандартов, регламентирующих процесс разработки ПО;
2) контроль за процессом разработки (для обеспечения выполнения стандартов);
3) создание отчетности о ходе процесса разработки для менеджера проекта и заказчика ПО.

92.

Существует два взаимодополняющих подхода к процессу
контроля качества:
1) проверки качества, когда программный продукт, сопровождающая документация и процесс разработки анализируются
группой проверяющих. Эта группа ответственна за проверку
соблюдения стандартов проекта, а также за соответствие документации этим стандартам. Любые отклонения от стандартов регистрируются и подаются на рассмотрение менеджеру проекта;
2) автоматизированная оценка ПО, когда программный продукт и его документация проверяются специальной
компьютерной программой, которая сопоставляет их со стандартами данного проекта. В такую автоматизированную проверку можно включить количественный контроль некоторых
характеристик ПО.

93.

Термин CALS (Continuous Acquisition and Lifecycle Support —
непрерывная информационная поддержка поставок и ЖЦ)
означает совокупность принципов и технологий информационной поддержки ЖЦ продукции на всех его стадиях.
CALS-технологии призваны служить средством, интегрирующим промышленные автоматизированные системы в единую многофункциональную систему. Целью интеграции является повышение эффективности создания и использования
сложных программных систем. Применительно к разработке
ПО повышение ее эффективности обеспечивается за счет
выполнения трех мероприятий, показанных на рис

94.

95.

Лекция 5. Организация процесса
обновления в информационной
системе. Регламенты обновления

96.

Обычно под обновлением ПО понимают
дополнения к программному обеспечению,
предотвращающие или устраняющие неполадки, повышающие безопасность либо
улучшающие производительность
компьютерной системы

97.

Наборы обновлений, исправлений и (или)
улучшений компьютерной программы, поставляемые в виде единого установочного
дистрибутива, принято называть пакетами
обновлений. Пакеты обновления обычно
нумеруются и кратко указываются как SP1,
SP2, SP3 и т. д.

98.

Патчи. Многие компании, например Microsoft или Autodesk,
выпускают пакет обновлений, когда число отдельных патчей
для конкретной программы достигает некоторого предела.
Патч (или «заплатка») — это небольшой программный код,
предназначенный для замены ошибочной и (или)
неоптимизированной части другой программы. Исправление
с помощью патчей может применяться к уже установленной
программе либо к ее исходным кодам. Сюда входят
исправление ошибок, изменение внешнего вида, улучшение
эргономичности или производительности программ, а также
любые другие изменения, которые разработчик пожелал
сделать.

99.

Хотфикс (Hotfix) — термин, применяющийся
для патчей, которые устанавливаются на
работающую систему без перезапуска. Часто
хотфиксы предназначены для решения
конкретных проблем той или иной организации
или конкретных пользователей и не выходят за
ее пределы. Также хотфиксы могут
предоставляться для конкретной конфигурации
оборудования и не работать с другими
системами.

100.

Процесс управления обновлениями ПО называется Patch
Management.
Различают разностные и суммарные пакеты обновлений.
Разностный пакет содержит только те обновления, которых
не было в предыдущих пакетах обновления, тогда как
суммарный пакет включает в себя содержимое всех
предыдущих обновлений.
Корпорация Microsoft называет разностные обновления
выпусками обновления (service release), применяя этот
термин, например, в контексте фразы: «Office 2016 должен
быть обновлен до выпуска обновления SR1 (читай Service
Release 1) перед установкой SP2».

101.

Различают обновления ОС и прикладного ПО.
Обновления для ОС и серверного ПО применяются в целях
поддержки надлежащего уровня безопасности и устранения
«дыр» в защите.
Обновления прикладного ПО (например, Microsoft Office,
Adobe Acrobat, клиентские части бизнес-приложений)
необходимы для решения возникших проблем с часто
используемыми или важными библиотеками и другими
частями исходного кода.

102.

Важность обновлений и их своевременную установку для
поддержания надлежащего уровня информационной
безопасности трудно переоценить. Однако иногда «заплатки»
уязвимостей одного приложения вызывают критические
неисправности в других приложениях. Приведем несколько
конкретных примеров, иллюстрирующих сказанное.

103.

1. Ежемесячное обновление Microsoft вызвало 25 апреля
2011 г. сбои в работе VMWare — программы, позволяющей
создавать «виртуальные машины».
2. Обновление для браузера Internet Explorer, выпущенное
Microsoft, содержало сразу две уязвимости: сбой в работе
браузера, а также переполнение буфера, которое позволяет
хакеру с помощью специального сайта запускать на уязвимой
машине код с привилегиями пользователя браузера (8
августа 2006 г.).

104.

3. Декабрьские обновления от Microsoft были предназначены
для исправления серьезной бреши безопасности
в применении шрифта OpenType. Обновление затрагивало
пользователей PowerPoint, Quark Xpress and CorelDraw.
Выпущенные обновления не позволяли программам
распознавать символы шрифта OpenType размером более 15
пикселов (12 декабря 2012 г.).
4. Установка обновлений Microsoft для драйверов режима
ядра (kernel mode drivers) привела к появлению синего экрана
смерти (BSOD) на компьютерах пользователей в августе
2014 г.
5. Обновление для офисного приложения PowerPoint 2013
привело к невозможности запуска приложения (10 февраля
2015 г.).

105.

Метод управления обновлениями является комбинацией
подхода к тестированию обновлений и подхода
к развертыванию релизов с обновлениями. Различают два
подхода к тестированию обновлений:
1) на локальных виртуальных машинах;
2) в полноценной тестовой среде.
В первом случае для создания виртуальных машин и сетей
используются либо продукт VMware, либо продукт Oracle
VirtualBox. Как правило, технология виртуализации
используется для небольших сетей с числом рабочих
станций 45…70, не более.

106.

Собственно виртуализация процесса тестирования ПО имеет
следующие достоинства:
• создание самой виртуальной машины не требует больших
затрат по времени;
• виртуальных машин на одной физической платформе может
быть несколько;
• каждая виртуальная машина имеет свои собственные
виртуальные аппаратные компоненты (память, процессор,
жесткий диск, сетевые адаптеры);
• возможность сделать «снимок» текущего состояния системы
и содержимого дисков одним кликом мыши, а затем в течение
очень короткого промежутка времени вернуться в исходное
состояние, что может быть очень полезным при условии
обнаружения обновления, установка которого вызывает
критические неисправности в системе.

107.

Второй вариант — тестирование с использованием
полноценной тестовой среды — применим для больших
промышленных сетей. Этот вариант гарантирует высокую
чистоту тестирования, поскольку использует те же подходы
к установке обновлений и инструменты для управления
обновлениями, что и в промышленной среде, причем
процесс тестирования можно упростить, используя всего
пару корпоративных компьютеров (так называемых тестовых
клиентов). Действительно, установив необходимые
обновления на тестовых клиентов и протестировав систему
после установки, можно увидеть последствия изменений
и убедиться в результате применения обновления, оказывая
при этом минимальное влияние на ИТ-инфраструктуру.

108.

Стадии процесса Patch Management. Процесс
управления обновлениями состоит из нескольких
этапов (стадий).
1. Подготовка тестовых клиентов.
2. Создание листов обновлений или патчлистов, включающих обновления, вышедшие
в текущем месяце и подходящие под определение
«требуемые обновления»
3. Развертывание в тестовой среде.
4. Развертывание на пилотных
пользователях — стадия Pre Deployment.

109.

110.

111.

112.

Тестирование программного
обеспечения в процессе
внедрения и эксплуатации

113.

Тестовые сценарии — это спецификации входных тестовых
данных и ожидаемых выходных данных плюс описание процедуры тестирования. Тестовые данные иногда генерируются
автоматически. Автоматическая генерация тестовых сценариев невозможна, поскольку результаты проведения теста
не всегда можно предсказать заранее.

114.

115.

Тестирование сборки. После того как протестированы все отдельные программные модули, выполняется сборка системы,
в результате чего создается частичная или полная программная система. При ее тестировании выявляются проблемы,
возникающие при взаимодействии программных модулей
системы. Тесты, проверяющие сборку, разрабатываются на
основе системной спецификации, причем тестирование сборки следует начинать сразу после создания работоспособных
версий программных модулей системы.

116.

• Тестирование интерфейса. Данное тестирование выполняется в тех случаях, когда модули или подсистемы интегрируются в большие системы. Цель тестирования интерфейса — выявить ошибки, возникающие в системе
вследствие ошибок в интерфейсах.

117.

Между компонентами программы могут быть интерфейсы следующих типов:
• параметрические интерфейсы, в которых ссылки на данные
и функции передаются в виде параметров от одного компонента
к другому;
• интерфейсы разделяемой памяти, в которых какой-либо блок
памяти совместно используется разными подсистемами. Одна
подсистема помещает данные в память, а другие подсистемы
используют эти данные;
• процедурные интерфейсы, в которых одна подсистема инкапсулирует (включает в себя) набор процедур, вызываемых из других
подсистем. Такой тип интерфейса имеют объекты и абстрактные
типы данных;
• интерфейсы передачи сообщений, в которых одна подсистема
запрашивает сервис у другой подсистемы посредством передачи
ей сообщения, причем ответное сообщение содержит результаты выполнения сервиса (пример: так работают системы «клиентсервер»).

118.

• Некорректное использование интерфейса имеет место,
когда при вызове модуля вызывающий модуль передает вызываемому параметры, нарушая порядок их следования
и (или) указывая неверное их число и (или) тип передаваемых данных.
• Неправильное понимание интерфейсов имеет место,
когда поведение вызываемого модуля не совпадает с ожидаемым. В этом случае поведение вызывающего модуля
становится непредсказуемым. Например, если программа
бинарного поиска вызывается для поиска заданного элемента в неупорядоченном массиве, то в работе программы
произойдет сбой.

119.

• Ошибки синхронизации интерфейсов встречаются
в системах реального времени, где используются
интерфейсы разделяемой памяти или передачи сообщений.
Подсистема-источник и подсистема-приемник данных могут
работать с разной скоростью. Если при проектировании
интерфейса не учитывать этот фактор, приемник может
получить доступ к устаревшим данным, потому что источник
к тому моменту еще не успел обновить совместно
используемые данные.

120.

Общие правила тестирования интерфейсов сводятся
к следующему:
1) просмотрите тестируемый код и составьте список всех вызовов, направленных к внешним компонентам. Разработайте
такие наборы тестовых данных, при которых параметры, передаваемые внешним компонентам, принимают крайние значения из диапазонов их допустимых значений. Вероятность
обнаружения несоответствия в интерфейсах в этом случае
будет максимальна;
2) если между интерфейсами передаются указатели, всегда
тестируйте интерфейс с нулевыми параметрами указателя;

121.

3) при вызове компонента через процедурный интерфейс используйте тесты, вызывающие сбой в работе компонента. Одна из
наиболее распространенных причин ошибок в интерфейсе — неправильное понимание спецификации компонентов;
4) в системах передачи сообщений используйте тесты с нагрузкой. Разрабатывайте тесты, генерирующие в несколько раз
большее количество сообщений, чем будет в обычной работе системы. Эти же тесты позволяют обнаружить проблемы синхронизации;
5) при взаимодействии нескольких компонентов через разделяемую память разрабатывайте тесты, которые изменяют порядок
активизации компонентов. С помощью таких тестов можно выявить сделанные программистом неявные предположения о порядке использования компонентами разделяемых данных.

122.

• Тестирование объектно-ориентированных систем. Системы,
разработанные по функциональной модели, и объектноориентированные системы (ООС) имеют следующие существенные отличия:
• объекты, как отдельные программные компоненты, представляют собой нечто большее, чем отдельные подпрограммы или функции;
• объекты, интегрированные в подсистемы, обычно слабо
связаны между собой, и поэтому сложно определить самый
верхний уровень системы;
• при анализе повторно используемых объектов их исходный
код может быть недоступным для испытателей.

123.

Применительно к ООС можно определить четыре уровня тестирования (терминология объектно-ориентированного программирования):
1) тестирование отдельных методов, ассоциированных
с объектами;
2) тестирование отдельных классов объектов;
3) тестирование кластеров (специальных групп) объектов —
обычно использует методы, основанные на сценариях;
4) тестирование системы — верификация и аттестация ООС
выполняется так же, как и для любых других типов систем.

124.

Инструментальные средства тестирования. В общем цикле
разработки ПО тестирование является самым дорогостоящим и трудоемким процессом, поэтому в настоящее время
создан и широко используется целый ряд автоматизирующих
этот процесс инструментальных средств. Рассмотрим функциональное взаимодействие отдельных блоков.

125.

126.

• Организатор тестов управляет выполнением тестов, отслеживая тестовые данные, ожидаемые результаты и тестируемые функции программы.
• Генератор тестовых данных порождает тестовые данные для тестируемой программы, либо выбирает их из базы
данных, либо использует специальные шаблоны для генерации случайных данных необходимого вида.
• Оракул (предыдущая версия программы или исследуемого
объекта) генерирует ожидаемые результаты тестов, которые
в блоке «Компаратор файлов» сравниваются с результатами тестирования, полученными от новой версии программы.

127.

• Компаратор файлов по результатам сравнения составляет отчет об обнаруженных различиях. Компараторы особенно важны
при сравнении различных версий программы. Различия в результатах указывают на возможные проблемы, существующие
в новой версии системы.
• Генератор отчетов формирует отчеты по результатам тестирования.
• Динамический анализатор подсчитывает, сколько раз выполняется каждый оператор тестируемой программы и выдает отчет
по результатам счета.
• Имитатор моделируют машину, на которой будет выполняться
программа (если это целевой имитатор) или моделирует взаимодействия с интерфейсом пользователя (если это имитатор
пользовательского интерфейса) или, наконец, генерирует последовательности повторяющихся транзакций, т. е. запросов к базе
данных (если это имитатор ввода-вывода).

128.

Эксплуатационная
документация

129.

Для изготовления, сопровождения,
тестирования и эксплуатации ПК создается
программная и эксплуатационная
документация. Ее разработка начинается
одновременно, а в особых случаях —
и раньше начала разработки собственно
ПК.

130.

• текст программы — запись программы с необходимыми
комментариями;
• описание программы — сведения о логической структуре
и порядке ее работы;
• порядок и методика испытаний — требования,
подлежащие проверке при испытании программы, а также
порядок и методы их контроля;
• техническое задание — спецификация требований
к создаваемому ПК с точки зрения заказчика;
• пояснительная записка — схема алгоритма, общее
описание алгоритма и (или) функционирования программы,
а также обоснование принятых технических
и экономических решений.

131.

Самостоятельную группу составляет эксплуатационная
документация — руководство пользователя и руководство
системного администратора.
Руководство пользователя содержит сведения о назначении
программы, об области ее применения, о применяемых
методах и ограничениях, конфигурации технических средств
и сведения, необходимые для общения пользователя
с персональным компьютером в процессе выполнения
программы.

132.

Основные документы ЕСПД, создание
которых оговаривает ГОСТ 19.301—79
«ЕСПД. Программа и методика испытаний.
Требования к содержанию
и оформлению», — это «Программа
и методика испытаний», «Описание
программы», «Пояснительная записка»,
«Текст программы» и «Описание
применения».

133.

Всю документацию на программный продукт можно
разделить на следующие категории:
• Документация управления проектом — организационные
документы, которыми обмениваются между собой те, кто
так или иначе участвует создании программы.
• Документация разработки — технические документы,
которыми обмениваются между собой те, кто так или иначе
участвует создании программы.
• Документация продукции — технические документы,
которые предоставляются потребителю в комплекте
поставки программы или отдельно от нее.

134.

Таблица 1. Документация разработки программы согласно ЕСПД
Документ
Источник
Аудитория
Содержание
Техническое
задание
Пояснительная
записка к
техническому
проекту
Программа и
методика
испытаний
аналитик
Проектировщик ПО
проектировщи программист
к ПО
аналитик
представитель
заказчика,
осуществляющий
приемку программы
Требования
к
программе
устройство программы
процедуры,
позволяющие
убедиться в
соответствии
программы
техническому заданию

135.

Таблица 2. Эксплуатационная документация на программный продукт
Документ
описание
программы
описание
применения
Аудитория
Примерное содержание
лица, принимающие
Назначение и основные
решения о
возможности программы,
приобретении, вводе в необходимые ей нее
эксплуатацию и
системные ресурсы,
способах использования входные и выходные
программы
данные
основная идея языка, его
пользователи
языка
синтаксис, элементы и
(программисты,
конструкции, встроенные
описание языка
операторы,
кодеры,
функции
верстальщики)

136.

Таблица 2. Эксплуатационная документация на программный продукт
Документ
Аудитория
паспорт
лица,
ответственные
эксплуатацию программы
руководство
администратора
руководство оператора
Ответственный пользователь
системы, обеспечивающий ее
целевое применение
операторы, работающие с
системой, частью которой
является программа
Примерное содержание
за
краткие сведения о программе и
условиях ее поставки
управление
учетными
записями
пользователей,
назначение
пользователям прав доступа, ведение
нормативно-справочной информации,
загрузка и выгрузка данных
порядок
выполнения
предусмотренных
операций,
сообщения
программы
и
предписанные оператору способы
реакции на них

137.

Таблица 2. Эксплуатационная документация на программный продукт
Документ
руководство
пользователя
Аудитория
Примерное содержание
назначение
и
возможности
Пользователи программы, т.е.
программы, ее основные концепции,
лица, применяющие ее для
интерфейс пользователя, порядок
решения собственных прикладных решения типовых задач, описание
задач
функций программы
руководство
программиста
программисты, сопровождающие
программу или использующие ее
в качестве платформы либо
средства разработки при создании
собственных программ
руководство
системного
администратора
(системного
программиста)
системные администраторы,
осуществляющие установку
программы и поддерживающие
систему в рабочем состоянии
архитектура
программы
или
создаваемых
на
ее
основе
приложений, описание программных
интерфейсов
к
ее
объектам,
протоколов обмена данными и т. п.
установка программы, ее интеграция
в систему, проверка правильности
функционирования,
устранение
аварийных ситуаций

138.

Таблица 2. Эксплуатационная документация на программный продукт
Документ
спецификация
справочная
система(«хелп»)
формуляр
Аудитория
Примерное содержание
лица,
ответственные
за комплект поставки программы
эксплуатацию программы
материал всех имеющихся
пользователи, операторы,
руководств
и
описаний,
администраторы, системные
краткие описания элементов
администраторы,
интерфейса
пользователя
программисты и др.
программы
краткие сведения о программе
и условиях ее поставки, записи
лица,
ответственные
за
эксплуатационного
о
эксплуатацию программы
возникающих сбоях и прочих
событиях такого рода

139.

Аппаратно-программные
платформы серверов и рабочих
станций.
Установка серверной части.
Виды серверного программного
обеспечения.

140.

При расчете параметров технических средств
учитывают:
• предполагаемые объемы баз данных;
• сложность алгоритмов обработки данных по
каждой задаче;
• количество пользователей и интенсивность их
работы с базой данных;
• требуемый уровень надежности всех элементов системы и др.

141.

В качестве искомых величин выступают:
• технические характеристики всех составляющих
комплекса технических средств (быстродействие
процессора, объем оперативной и дисковой памяти
и др.);
• способы организации вычислительных процессов,
режимов работы;
• параметры, характеризующие эффективность работы технических средств и др.

142.

Первый признак, по которому подразделяются компьютеры — платформа.

143.

Серверы.
Новое поколение информационных систем получило возможности использования мощных
центральных сетевых компьютеров — серверов. Современные ОС компьютеров в существенной степени строятся на новой платформе,
ориентированной на серверы. Разнотипные
компьютеры — от дешевой настольной рабочей
станции до мощного сервера — успешно
объединяются в комплексы, обеспечивая надежные решения архитектуры информационных систем.

144.

Серверы используют новые более мощные модели процессоров. Компьютерная индустрия
планомерно переходит на 64-битные архитектуры серверов и компьютерных приложений. Это
требует от пользователей освоения как новых
процессоров, так и соответствующих ОС. Постепенно осуществляются перенос приложений
на новую платформу и их оптимизация.

145.

Кластерная структура сервера. Кластер представляет собой
многомашинный компьютерный комплекс, который с точки
зрения пользователя:
• является единой системой;
• обеспечивает высокую надежность (отказоустойчивость);
• имеет общую файловую структуру;
• обладает свойством эффективной масштабируемости —
производительности при добавлении ресурсов;
• управляется (администрируется) как единая система.

146.

Главные же качества кластеров — высокая надежность
и масштабируемость. В отличие от систем с «горячим резервированием» все компьютеры в кластере не простаивают,
а выполняют полезную работу. В результате затраты на дополнительное оборудование являются платой не только за
надежность, но и за производительность.

147.

Кластер — это несколько компьютеров, соединенных коммуникационным каналом и имеющих доступ к общекластерным ресурсам, к которым прежде всего относятся дисковые накопители

148.

Основой открытых систем является стандартизованная ОС.
Сегодня на эту роль претендуют ОС UNIX, Windows.
Технологии и стандарты открытых систем обеспечивают производство ПО со свойствами мобильности и интероперабельности:
свойство мобильности обеспечивает сравнительную простоту
переноса ПО на другую аппаратно-программную платформу,
соответствующую стандартам;
интероперабельность означает возможность простого создания новых программных систем на основе использования готовых компонентов со стандартными интерфейсами.

149.

Виды серверного программного
обеспечения.
Серверное ПО – это ПО, предоставляющее услуги или
функции на компьютере, выступающим в качестве среды

150.

Виды серверного ПО:
• Файловый сервер – предназначен для обеспечения доступа к
файлам, хранящимся на серверных дисках организации.
• Сервер баз данных – обеспечивает хранение, обработку и доступ к
базам данных компании, осуществляемы с клиентских компьютеров.
• Сервер приложений – осуществляет программную обработку
данных, которые посылает ему пользователь, и выдает этому
пользователю конечный результат.
• Веб-сервер – отвечает за выдачу интернет страницы. Может
одновременно обрабатывать большое количество запросов.
• Почтовый сервер – предназначен для отправки, получения,
хранения и распределения электронных писем.
• Брандмауэр (файервол) – обеспечивает защиту внутренней сети и ее
ресурсов от интернет-атак.
• Прокси-сервер – служба, позволяющая выполнять клиентам
косвенные запросы к другим сетевым службам.

151.

Прокси-сервер скрывает от внешних пользователей структуру
сети, обеспечивает доступ к сети по одному IP-адресу.
Позволяет вмести с DNS-сервером производить
автоматическую раздачу и назначение IP-адреса.
• DNS-сервер – служит для автоматического учета и выдачи
уникальных IP-адресов всем узлам, которые к нему
обращаются.
• Сервер удаленного доступа – позволяет получать через
Интернет доступ к локальной сети.
• Принт-сервер – позволяет получить доступ к сетевому
принтеру.