Алгоритмизация, программирование, тестирование, ввод в эксплуатацию отдельных ПС в АСУП объекта ТЭК

1.

Разработка и внедрение
программных систем
Лекция 5. Алгоритмизация, программирование, тестирование, ввод
в эксплуатацию отдельных ПС в АСУП объекта ТЭК.
Лектор: Крючков Алексей Вячеславович

2.

Изучаемые вопросы
5.1. Формирование алгоритмов из требований, как процесс.
5.2. Реализация алгоритмов в коде, как процесс. Восходящее и
нисходящее программирование. Процедуры и модули.
Тестирование и отладка.
5.3. Понятие архитектуры. Стандарты IDEF.
5.4. Ввод в эксплуатацию ПС.
Крючков А.В.
2

3.

Вопрос 1. Формирование алгоритмов
Каскадная
Модели ЖЦ
С промежуточным
контролем
Эволюционная
Инкрементная
Крючков А.В.
3

4.

Вопрос 1. Формирование алгоритмов
Мой личный опыт в ЖЦ ПС (около 15 лет).
0 этап: предварительное обсуждение с перспективным заказчиком и
неофициальная фиксация его пожеланий по будущему ПС.
1 этап: описание требований заказчиком (в техническом задании - ТЗ).
2 этап: создание и согласование документа «Постановка задачи».
3 этап: разработка алгоритма и документа «Алгоритм».
4 этап: программирование и отладка; проведение испытаний.
5 этап: создание документов «Описание программы» и «Инструкция
пользователю по эксплуатации».
6 этап: установка программы на ПЭВМ пользователя; завершение испытаний и
передача документации.
7 этап: подписание «Акта приёмо-сдаточных испытаний», сдача программы и
документации на неё в фонд алгоритмов и программ.
Крючков А.В.
4

5.

Вопрос 1. Формирование алгоритмов. Эпоха 1
Согласно [5] (ЕСПД, ГОСТ 19.102-77), для ПО задаётся свой вариант ЖЦ,
коррелирующий с ГОСТами по АСУ.
На стадии ЖЦ «технический проект» специалистами выполняются 2 этапа:
- Этап разработки технического проекта;
- Этап утверждения технического проекта.
При разработке технического проекта ПО (этап 1) выполняются:
1.1. уточнение структуры входных и выходных данных
1.2. разработка алгоритма решения задачи
1.3. определение формы представления входных и выходных данных
1.4. определение семантики и синтаксиса языка
1.5. разработка структуры программы
1.6. окончательное определение конфигурации технических средств
Крючков А.В.
5

6.

Вопрос 1. Формирование алгоритмов. Эпоха 1
Существует раздел математики (математической логики), называемый
теорией алгоритмов. Он изучает общие свойства и закономерности
алгоритмов, формальные модели их представления, а своей главной
задачей считает феномен алгоритмической неразрешимости задач.
Данный раздел используется для обоснования математики, как науки,
создавая основу для вычислительных наук.
К вычислительным относят науки, которые используются как науки об
информационных технологиях (Computer Science – CS), так и науки об
организации вычислительных процессов, вычислительных машин, систем
и сетей.
Крючков А.В.
6

7.

Вопрос 1. Формирование алгоритмов. Эпоха 1
Специалистов, преобразующих логическую структуру решаемой задачи в
форму, удобную для программирования, называют алгоритмистами.
При этом считается, что программисты занимаются почти исключительно
кодированием алгоритмов, составленных постановщиками задач, и
длительной отладкой программ.
Очевидный разрыв процесса в ЖЦ программ!!!
В ЖЦ алгоритмизация задачи (для решения в АСУ = предварительная
стадия синтеза программы) звено в цепи её решения; алгоритмист
разрабатывает схему её решения, которая затем передаётся
программисту.
Крючков А.В.
7

8.

Вопрос 1. Формирование алгоритмов. Эпоха 2
АЛГОРИТМ – конечное упорядоченное множество точно определенных
правил для решения конкретной задачи ([1], п.4.39).
Алгоритмический язык: Искусственный язык, предназначенный для
выражения алгоритмов ([1], п.4.40).
Программа: Данные, предназначенные для управления конкретными
компонентами системы обработки информации в целях реализации
определенного алгоритма ([1], п. 4.1075).
Функция: Реализация в программе алгоритма, по которому
пользователь или программа могут частично или полностью
выполнять решаемую задачу ([1], п. 4.1498).
Крючков А.В.
8

9.

Вопрос 1. Формирование алгоритмов. Эпоха 2
АЛГОРИТМ – предписание о выполнении в соответствующем порядке
деятельности человека, необходимой для достижения определенной цели
([2], п.3.1).
алгоритмизированная деятельность: Деятельность человека, осуществляемая
на основе системы условий и правил, предназначенных в качестве
информационного средства для обеспечения упорядоченного проведения
подсознательно или сознательно умственных действий человеком, как
субъекта социума в его жизнедеятельном существовании, с целью
направленно-организованного алгоритмизированного выполнения им
определенных познавательных, предметно-практических и творческих задач
([2], п.3.2).
алгоритмизация: Создание алгоритма(ов) для выполнения умственных
действий человеком с целью проведения им соответствующей
познавательной, предметно-практической и творческой
алгоритмизированной деятельности ([2], п.3.3).
Крючков А.В.
9

10.

Вопрос 1. Формирование алгоритмов. Эпоха 2
алгоритмический процесс: Процесс логико-упорядоченного,
выполнения умственных действий мышлением человека при
проведении соответствующей деятельности ([2], п.3.4).
операторы алгоритмизированных процессов: Установленные
минимально необходимые локализовано-структурированные действия
для проведения переработки состояния соответствующего участка (шага)
алгоритмизированного процесса в другое его состояние ([2], п.3.19).
операционная схема: Документ, в котором, в виде определенных
обособленных информационных образований, [например, условных
графических изображений (в виде репрезентирующих
клиаратизирующих изображений)], показаны процедуры по обращению
с техническим изделием и связи между ними ([2], п.3.21).
Крючков А.В.
10

11.

Вопрос 1. Формирование алгоритмов. Эпоха 2
система "человек-информация" (в психической деятельности): Система,
состоящая из человека и воспринимаемой им информации,
образующаяся с появлением определенных информационно-обменных
процессов между человеком и соответствующими внешними и
внутренними относительно человека информационными средами и
обеспечивающая выполнение в локализованном пространстве и времени
необходимой психической деятельности с проведением человеко
информационного взаимодействия и возникновением психических
явлений ([2], п.3.24).
Это – граница, по которой проходит процесс перевода требований в
алгоритм.
Крючков А.В.
11

12.

Вопрос 1. Формирование алгоритмов. Эпоха 2
Алгоритмизированное представление сведений - это одно из основных
информационных методических средств, используемых для направленного
информационно-семантического управления интеллектом технических
специалистов (как при проведении ими познавательной, так и творческой
практической деятельности), применяемое в ноон-технологии, являющейся
нормативно-регулируемой информационной технологией в решении
проблемы человеческого фактора в функционировании техносферы ([2], п.5.8).
ноон-технология: Технология создания информации в виде, соответствующем
психофизиологии человека, для реализации оптимизированных
информационно-обменных процессов в системе «человек-информация» при
создании, хранении, передаче, применении сообщений. [ГОСТ Р 43.0.2-2006,
статья А.2 (приложение А)] ([4], п.3.28)
Крючков А.В.
12

13.

Вопрос 1. Формирование алгоритмов. Эпоха 2
Клиаратизированное описательное и инструкционное алгоритмическое
представление сведений при использовании их в качестве
соответствующей информационной поддержки в технической
деятельности может обеспечить создание на различных этапах ЖЦ
изделия (при взаимодействии специалистов с техникой) необходимых
условий для контроля достоверности этих сведений ([2], п.5.18).
Для алгоритмизированного представления сведений в ФС могут
использоваться РКИ для замещения технических явлений и сущностей как
для описательного, так и для инструкционного изложения этих сведений
([2], п.5.19).
Крючков А.В.
13

14.

Вопрос 1. Формирование алгоритмов. Эпоха 2
РКИ - репрезентирующе-клиаратизирующие изображения;
ФС - формат сообщения ([2], п.4).
клиаратизированное представление информации: Представление
информации в виде, обеспечивающем повышенный уровень ее
понимания при восприятии и использовании ([3], п.3.10).
техносфера: Область распространения техники, определяемая
потребностями социума ([3], п.3.16).
Информационный процесс в техносфере - процесс, проявляющийся в
способности к отражению соответствующим техническим объектом,
оператором воздействия другого технического объекта в какой-либо
технической информационной среде ([3], п.5.3).
Крючков А.В.
14

15.

Вопрос 1. Формирование алгоритмов. Эпоха 2
Алгоритмизированное представление технических сведений - это
отражение в виде информационных моделей с применением
обособленных структурных информационных образований,
представленных в виде изображений преимущественно образного
восприятия, сведений:
- по устройству технических предметных сред, входящих в них
предметных компонентов;
- по процессам и ситуациям связанных с функционированием
предметных сред и предметных компонентов, водящих в эти среды;
- по процессам и ситуациям, относящимся к проведению технической
деятельности и обращению человека с техникой ([2], п.5.20).
Крючков А.В.
15

16.

Вопрос 1. Формирование алгоритмов.
Основным вариантом реализации алгоритмов
является блок-схема.
В единой системе программной документации
(ЕСПД) есть ГОСТ 19.701-90 «Схемы алгоритмов
программ, данных и систем».
Примеры обозначений приведены на рис.
Документ «Алгоритм» комплектуется набором блоксхем, объясняющих как выходные и рассчитываемые
данные получаются из входных.
Крючков А.В.
16

17.

Вопрос 1. Формирование алгоритмов.
Альтернативой блок-схемам является язык UML.
При его использовании необходимо создавать
несколько видов диаграмм. Это диаграммы:
- вариантов использования;
- классов;
- кооперации;
- последовательности;
- состояний;
- деятельности;
- компонентов.
Пример диаграммы использования при обращении
студента в библиотеку дан на рис. Овалам будут
соответствовать программы или функции.
Крючков А.В.
17

18.

Вопрос 1. Формирование алгоритмов.
Ещё одним вариантом отрисовки алгоритмов
являются сети Петри. Это математический
объект, используемый для моделирования
динамических дискретных систем. Кружки
отвечают за состояния. Стрелки – за
перемещения. Точка показывает текущее
положение.
На рис. показан вариант моделирования
очереди на выполнение заданий на MainFrame.
Точка в положении «Процессор свободен»
говорит об ожидании поступления задания.
Крючков А.В.
18

19.

Вопрос 1. Формирование алгоритмов.
Вспомним, что требования, формируемые в описании программисту
содержат:
- Точное описание входных данных, в т.ч. тех, которые не указаны
пользователем, но необходимы для отчётов и расчётов;
- Детальное указание для каждой позиции данных о том, как в неё будет
вводится информация: из классификатора, с клавиатуры, по сети;
- Детальный список ограничений на вводимую информацию;
- Детальный перечень выводимых отчётов, желательно с указанием того,
какие входные или рассчитываемые данные туда попадут по каждой
позиции данных;
- Детальный перечень расчётов, с указанием того, какие данные для них
будут просто введены с клавиатуры, какие получены из предварительных
расчётов и сохранены, какие будут попадут в отчёт.
Крючков А.В.
19

20.

Вопрос 1. Формирование алгоритмов.
Возвращаясь к жизненному опыту и используя требования, формируемые в
описании программисту, можно сформировать альбом алгоритмов с:
- Детальным указанием для каждой позиции данных методов ввода: из
классификатора, с клавиатуры, по сети, – с учётом ограничений на
вводимую информацию;
- Детальным указанием способов формируемых отчётов, с указанием того,
какие входные или рассчитываемые данные туда попадут по каждой
позиции данных;
- Детальный перечень расчётов, с указанием того, какие данные для них
будут просто введены с клавиатуры, какие получены из предварительных
расчётов и сохранены, какие будут попадут в отчёт.
Алгоритмы покажут как и какие выходные и рассчитываемые данные
получаются из входных.
Крючков А.В.
20

21.

Вопрос 2. Реализация алгоритмов в коде
Наиболее адекватным в плане определений в области синтеза ПО
является ГОСТ 19781-90 ([6]). Многие данные в нём определения
позволяют точно формулировать действия при написании и
отладке программ.
Последовательность действий:
- Получение данных от алгоритмиста (на основе D-требований);
- Определение необходимых систем программирования (СП) и
системы управления базами данных (СУБД);
- Написание исходных кодов программ;
- Отладка.
Крючков А.В.
21

22.

Вопрос 2. Реализация алгоритмов в коде
Система программирования – система, образуемая языком
программирования, компиляторами или интерпретаторами
программ, представленных на этом языке, соответствующей
документацией, а также вспомогательными средствами для
подготовки программ к форме, пригодной для выполнения. ([6], п.21)
Для отладки в СП нужны компиляция (для одного файла это
трансляция), работа редактора связей и создание исполняемого
файла. Компиляция – процесс создания объектного кода из
нескольких связанных файлов исходного кода на ЯП.
В случае использования интерпретаторов компиляция не требуется.
Крючков А.В.
22

23.

Вопрос 2. Реализация алгоритмов в коде
Спецификация программы – Формализованное представление
требований, предъявляемых к программе, которые должны быть
удовлетворены при ее разработке, а также описание задачи, условия
и эффекта действия без указания способа его достижения. ([6], п.49)
Трансляция программы – Преобразование программы,
представленной на одном языке программирования, в программу на
другом языке и в определенном смысле равносильную первой. ([6],
п.50)
Компиляция – Трансляция программы с языка высокого уровня в
форму, близкую к программе, на машинном языке. ([6], п.51).
Крючков А.В.
23

24.

Вопрос 2. Реализация алгоритмов в коде
Большинство сложных задач АСУ (сложных программ ПО АСУ) требуют
разбиения на более простые. Этот процесс в программировании
называется нисходящим или нисходящим программированием. Его
перенесли без изменений в область проектирования.
Пример дан на рис.
Крючков А.В.
24

25.

Вопрос 2. Реализация алгоритмов в коде
Есть и противоположный способ решения сложных задач АСУ
(разработки сложных программ ПО АСУ). Это процесс, в котором более
простые изначально модули программ постепенно объединяются в
более сложные. В этом случае речь идёт о восходящем
программировании.
Пример дан на рис.
Крючков А.В.
25

26.

Вопрос 2. Реализация алгоритмов в коде
Как правило, большинство современных СП содержат библиотеки
встроенных (или стандартных) функций, используемых
программистами для восходящего программирования при решении
задач АСУ.
В различных версиях СП как наборы встроенных подпрограмм и
функций, так и их использование (в случае, если идентификатор
данного объекта остался прежним) ИЗМЕНЯЮТСЯ. Это – основная
причина трудностей при появлении новых релизов.
В интегрированных системах вопрос трудностей программистов в этой
точке пытались переложить с сотрудников объекта ТЭК на внешнего
провайдера.
Крючков А.В.
26

27.

Вопрос 2. Реализация алгоритмов в коде
Отладка программ решает 2 задачи:
- устранение ошибок, препятствующих их устойчивой работе;
- определения соответствия получаемых при их работе результатов
требованиям, зафиксированным на этапе формулировки требований
(см. «спецификация программы»).
Задачи отладки формулировались в первую эпоху. Вторую задачу отладки в
третьей эпохе можно отождествить с верификацией. При этом, решение
этой задачи отладки программ является составной частью их тестирования.
По неподтверждённой статистике до 70% времени при синтезе программ
уходит на их отладку. Это касается и интегрированных систем (ERP, CASE,
CALS и т.п.), и интерпретаторов.
Крючков А.В.
27

28.

Вопрос 2. Реализация алгоритмов в коде
При использовании СП, позволяющей создавать исполняемый файл,
программисты при отладке сталкиваются с тремя видами ошибок:
- Ошибки компиляции;
- Ошибки при работе редактора связей;
- Ошибки выполнения при работе исполняемого файла.
При использовании интерпретатора при отладке возникают сбои,
связанные с неправильным употреблением операторов ЯП и с
неправильной работой кода программы.
Крючков А.В.
28

29.

Вопрос 2. Реализация алгоритмов в коде
При тестировании перед внедрением
следует рассматривать 3 вида оценок ПО:
- Оценка соответствия заявленным
требованиям (C-требованиям);
- Оценка работы программы без сбоев
самой по себе;
- Оценка работы программы в среде других
программ ПО АСУ ТП.
Крючков А.В.
29

30.

Вопрос 2. Реализация алгоритмов в коде
Оценка соответствия заявленным требованиям (C-требованиям).
Этот этап связан не только с проверкой реализации в программе того,
что записано в техническом задании (ТЗ) – документе,
предназначенном для аккумулирования и фиксирования (заказчиком
и разработчиком) предполагаемых к реализации в коде требований.
При такой проверке в идеале необходимо формально оценить:
- выполнен в программе пункт, указанный в ТЗ или нет;
- если выполнен, то насколько правильно.
Также следует учесть не попавшие в ТЗ пожелания пользователя, для
которого программа создавалась.
Крючков А.В.
30

31.

Вопрос 2. Реализация алгоритмов в коде
Критерии соответствия заявленным C-требованиям.
Эффективность, результативность – точность и полнота, с которой пользователи достигают
определенных целей ([7], п.4.1.1)
Удовлетворенность – способность продукта или системы удовлетворить требованиям пользователя в
заданном контексте использования. ([7], п.4.1.3)
Полноценность – степень удовлетворенности пользователя достижением прагматических целей,
включая результаты использования и последствия использования. ([7], п.4.1.3.1)
Удовольствие – степень удовольствия пользователя от удовлетворения персональных требований.
([7], п.4.1.3.3)
Функциональная пригодность – степень, в которой продукт или система обеспечивают выполнение
функции в соответствии с заявленными и подразумеваемыми потребностями при использовании в
указанных условиях. ([7], п.4.2.1)
Удобство использования – степень, в которой продукт или система могут быть использованы
определенными пользователями для достижения конкретных целей с эффективностью,
результативностью и удовлетворенностью в заданном контексте использования. ([7], п.4.2.4)
Завершенность – степень соответствия системы, продукта или компонента при нормальной работе
требованиям надежности. ([7], п.4.2.5.1)
Готовность – степень работоспособности и доступности системы, продукта или компонента. ([7],
п.4.2.5.2.)
Крючков А.В.
31

32.

Вопрос 2. Реализация алгоритмов в коде
Оценка работы программы без сбоев самой по себе.
Этот этап является продолжением отладки и гораздо больше похож на
те методики тестирования, которые описаны в обширной технической
литературе.
Программа должна быть проверена максимально полно на разных
исходных данных, чтобы при всех случаях её прогона она работала
без сбоев.
В терминологии ГОСТов по АСУ этот этап оценки соответствует этапу
опытной эксплуатации программы.
Крючков А.В.
32

33.

Вопрос 2. Реализация алгоритмов в коде
Оценка работы программы в среде других программ ПО АСУ ТП.
Этот этап завершает отладку и тестирование. Считается, что к моменту
его проведения все программы, входящие в ПО, проверены на предмет
соответствия выполнения C-требований и работают без сбоев как
отдельные модули.
ПО АСУ ТП представляет собой набор взаимодействующих программ, в
котором работа каждой отдельной программы не должна приводить к
сбою другой. Архитектурные требования нужны для этой части ПО.
В терминологии АСУ это – опытная эксплуатация ПО АСУ ТП, в другой
терминологии – системное тестирование.
Крючков А.В.
33

34.

Вопрос 3. Понятие архитектуры
Архитектура (системы) – основные понятия или свойства системы в
окружающей среде, воплощенной в ее элементах, отношениях и
конкретных принципах ее проекта и развития. ([8], п.3.2)
Описание архитектуры – рабочий продукт, используемый для выражения архитектуры. ([8], п.3.3)
Структура архитектуры – условности, принципы и практики для описания архитектур, установленные в пределах заданной области
применения и/или объединения заинтересованных сторон. ([8], п.3.4)
Архитектура информационно-вычислительной сети – число уровней
управления и типы используемых протоколов (учебник по сетям).
Крючков А.В.
34

35.

Вопрос 3. Понятие архитектуры
Архитектура (системы) – структура системы или ИТ-услуги, включающая
взаимоотношения между компонентами и средой, в которой они находятся;
архитектура также включает стандарты и руководящие документы, которые
определяют проектирование и развитие системы (Глоссарий терминов и
определений, ITIL® V3 Glossary Russian Translation v0.92, 30 Apr 2009, ITIL® V3
Translation Project, М., ИТ-эксперт, 2011, с.7)
Архитектура системы – набор основных правил, определяющих организацию
системы ([9], с.127):
- совокупность структурных элементов системы и связей между ними;
- поведение элементов системы в процессе их взаимодействия;
- иерархия подсистем, объединяющих структурные элементы;
- архитектурный стиль (используемые методы и средства описания архитектуры).
Крючков А.В.
35

36.

Вопрос 3. Понятие архитектуры
Архитектура корпоративная – предопределяет архитектуру
интегрированной бизнес-модели компании и составляющих ее
компонент-моделей процессов и проектов, моделей систем
управления, функциональных и организационных моделей и т. д.;
корпоративная архитектура интегрирует локальные описания
компании (Лозовицкий И.Б., Корпоративные архитектуры и их
развитие, материалы семинара «ИТ-директор» в Moscow Business
School, М., 2010).
Крючков А.В.
36

37.

Вопрос 3. Понятие архитектуры
Архитектура программная – основная организация системы
программного обеспечения, воплощенная в ее компонентах, их
взаимоотношениях друг с другом и со средой окружения, а также
принципы, направляющие проектирование и развитие этой системы.
(ГОСТ Р 54136-2010 Системы промышленной автоматизации и
интеграция. Руководство по применению стандартов, структура и
словарь, п.108)
Архитектура программная – описание системы ПО, включающее
совокупность структурных элементов системы и связей между ними;
поведение элементов системы в процессе их взаимодействия и
иерархию подсистем, объединяющих структурные элементы ([9], с.127)
Крючков А.В.
37

38.

Вопрос 3. Понятие архитектуры
Архитектурное представление –
упрощённое описание (абстракция)
системы с конкретной точки
зрения, охватывающее
определённый круг интересов и
опускающее объекты,
несущественные с данной точки
зрения ([9], с.127)
Пример показан на рис.
Крючков А.В.
38

39.

Вопрос 3. Понятие архитектуры
Архитектурное представление АСУП на
рис. позволяет понять, сколько в ней
уровней и как взаимодействуют в ней
крупные составные части.
ПО является подсистемой каждой из
АСУТП в АСУП.
Разбор по уровням и составным частям
архитектурного представления сродни
нисходящему программированию.
Крючков А.В.
39

40.

Вопрос 3. Понятие архитектуры
Архитектура программная – основная организация системы
программного обеспечения, воплощенная в ее компонентах, их
взаимоотношениях друг с другом и со средой окружения, а также
принципы, направляющие проектирование и развитие этой системы.
(ГОСТ Р 54136-2010 Системы промышленной автоматизации и
интеграция. Руководство по применению стандартов, структура и
словарь, п.108)
Архитектура ПО – описание системы ПО, включающее совокупность
структурных элементов системы и связей между ними; поведение
элементов системы в процессе их взаимодействия и иерархию
подсистем, объединяющих структурные элементы ([9], с.127)
Крючков А.В.
40

41.

Вопрос 3. Понятие архитектуры
Архитектура клиент-сервер – обобщённое
представление о взаимодействии двух компонент
информационной технологии (технического и/или
программного обеспечения) в вычислительных
системах и сетях (Т.Л. Партыка, И.И. Попов,
Вычислительная техника, 2-е изд., испр. и доп.,
Форум, М., 2010, с.142)
По сути это механизм передачи части вычислений
и/или данных с менее мощных ПЭВМ клиентов на
более мощные сервера.
Этот вид архитектуры относится к приложениям и
сервисам.
Крючков А.В.
41

42.

Вопрос 3. Понятие архитектуры
Существует несколько вариантов клиент-серверной архитектуры:
- Автономная работа приложений на ПЭВМ клиента с периодической
записью данных на сервер;
- Работа приложения с данными на ПЭВМ клиента и передачей на сервера
части или всех объёмных вычислений;
- Работа приложения с вычислениями на ПЭВМ клиента и передачей на
сервера части или всех данных;
- Работа приложения на ПЭВМ клиента с передачей вычислений и всех
данных на сервера (в т.ч. веб-вариант);
- Выполнение на сервере всех клиентских операций, включая загрузку
операционной системы и т.п.
В зависимости от выполнения этих условий определяется «толщина»
клиента – типа выполняемого на ПЭВМ пользователя приложения.
Крючков А.В.
42

43.

Вопрос 3. Понятие архитектуры
Облачные вычисления – один из
вариантов клиент-серверной
архитектуры. Для них характерно
наличие блока серверов, обычно
называемого центром обработки
данных (ЦОД), выполняющего
одновременно роль и сервера
приложений, и сервера БД, и файлсервера, и хранилища для
резервного копирования данных.
Крючков А.В.
43

44.

Вопрос 3. Понятие архитектуры
Другой вариант клиент-серверной архитектуры
– веб-приложения.
Пользователь работает через браузер с вебстраницей, написанной на языке разметки и
содержащей скрипты.
Данные и вычисления при этом в основном
выполняются на серверах через запросы.
Крючков А.В.
44

45.

Вопрос 3. Стандарты IDEF
Для моделирования архитектуры и
поведения сложных систем разработаны
стандарты IDEF.
Они позволяют отображать модели
деятельности, развития, информационных
потоков, документирования процессов в
сложных системах.
ПС относятся к сложным. Пример схемы в
IDEF приведен на рис.
Крючков А.В.
45

46.

Вопрос 3. Стандарты IDEF
Краткий перечень стандартов IDEF:
- IDEF0 – функциональное моделирование;
- IDEF1 – моделирование информационных потоков;
- IDEF2 – динамическое моделирование развития системы;
- IDEF3 – документирование технологических процессов в системе;
- IDEF4 – отображение структуры объектов в системе и их взаимодействие;
- IDEF5 – словарь терминов и правил для описания состояний системы;
- IDEF6 - причины, обстоятельства, скрытые мотивы моделирования систем
управления предприятиями;
- IDEF7 – аудит информационных систем;
- IDEF8 – разработка интерфейсов взаимодействия оператора с системой;
- IDEF9 – исследование бизнес-ограничений.
Подробное описание в [11], с.266 – 274.
Крючков А.В.
46

47.

Вопрос 3. Стандарт IDEF0
IDEF0 используется для создания
функциональной модели, отображающей
структуру и функции системы, а также
потоки информации и материальных
объектов, преобразуемые этими
функциями ([10], Введение)
Рис. слева – вариант применения IDEF0 к
процессу заправки.
Рис. справа – [10],
п.6.1, рис.3.
Крючков А.В.
47

48.

Вопрос 3. Стандарт IDEF3
IDEF3 предназначен для
документирования технологических
процессов в системе.
С помощью него можно описать
сценарии работы или
последовательность операций в
процессе ([11], с.267)
На рис. показан сценарий процесса
ремонта в квартире в нотации IDEF3.
Крючков А.В.
48

49.

Вопрос 4. Ввод в эксплуатацию ПС
После разработки ПС необходимо внедрение, которое в первую
эпоху было принято называть вводом в эксплуатацию. Это
последний этап синтеза ПС, который ранее было принято разбивать
на две части: опытную и промышленную.
В ходе опытной эксплуатации ПС заказчику (клиенту) передаётся
программа в виде приложения или сервиса и инструкция,
объясняющая как с ними работать. Клиент «пробует на вкус»
сдаваемую ПС, ошибаясь сам или находя ошибки разработчика. И
тот мгновенно их исправляет.
Клиент по сути ставит опыты над сдаваемым приложением.
Крючков А.В.
49

50.

Вопрос 4. Ввод в эксплуатацию ПС
Под промышленной эксплуатацией подразумевается установка ПС
на рабочие места клиентов АСУ ТП (АСУП).
Опыты над сдаваемым приложением прекращаются, и оно
становится составной частью реального технологического процесса.
Впоследствии для его эксплуатации появляется внутренний
рабочий документ, утверждаемый руководством предприятия, в
котором инструкция, переданная в ходе опытной эксплуатации,
становится частью технологической документации.
После этого можно говорить о ВНЕДРЕНИИ ПС в технологический
или иной процесс объекта ТЭК.
Крючков А.В.
50

51.

Вопрос 4. Ввод в эксплуатацию ПС
Для выполнения описанных задач в ходе опытной и промышленной
эксплуатации при предусмотрено проведение ряда мероприятий
([11], с. 153):
- Подготовка объекта к внедрению АСУ (подготовка техники,
информационной базы и кадров, назначение ответственных за
отдельные ПС);
- Опытная эксплуатация задач и комплексов и сдача их в
промышленную эксплуатацию;
- Сдача АСУ ведомственной комиссии в промышленную
эксплуатацию.
Крючков А.В.
51

52.

Вопрос 4. Ввод в эксплуатацию ПС
Оформляемые документы при внедрении ([11], с.154):
1. Приказ о создании ведомственной комиссии по приёмке.
2. Акт завершения работ.
3. Акт приёмки в опытную эксплуатацию.
4. Акт приёмки в промышленную эксплуатацию.
5. План-график работ по приёмке.
6. Приказ о проведении работ по приёмке.
7. Программы испытаний ПС, работы комиссии и опытной
эксплуатации.
8. Протоколы испытаний (по каждому приложению или сервису).
9. Протоколы согласования изменений и отклонений от ТЗ.
Крючков А.В.
52

53.

Вопрос 4. Ввод в эксплуатацию ПС
Во вторую эпоху заговорили об исчезновении программирования
на стороне заказчиков (внутренней разработки) и переходе всех
объектов информатизации на интегрированные системы.
Интегрированными называли системы, модули в которых являлись
«готовыми» рабочими местами клиентов. В результате термин
«ВНЕДРЕНИЕ» получил новые коннотации.
Вспомним лекцию 2: «Внедрение ПО – это процесс принятия и
интеграции программного приложения в системы и рабочие
процессы вашей компании». Установка приложения на смартфон –
это уже внедрение!!! Беда в том, что в этом случае не приложение
«подгоняется» под процессы в компании, а процессы в компании
подгоняются под приложение.
Крючков А.В.
53

54.

Вопрос 4. Ввод в эксплуатацию ПС
Определение готовности дано выше. Что в результате?
«Вот как обычно выглядит типовой процесс внедрения ПО в большинстве
случаев:
1. Получили перечень задач, которые нужно реализовать.
2. Доработали программный продукт с учетом пожеланий клиента.
3. Установили везде программу, настроили.
4. Провели краткое обучение.
5. Оставили инструкцию, написанную техническим языком и понятную, чаще
всего, только системному администратору.
Именно такой вариант работы я не единожды наблюдал лично, во время
работы в компаниях-партнерах 1С. Кроме того, многие мои клиентыбизнесмены, столкнувшиеся с внедрением различных программных
продуктов, также рассказывали именно о таком варианте.» ([12])
Крючков А.В.
54

55.

Вопрос 4. Ввод в эксплуатацию ПС
Причина – несоответствие бизнес-целей разработчиковвнедрителей ПО (ИТ-компаний) и их клиентов. У клиентов ИТкомпаний, внедряющих ПО, «задача – решить проблемы в бизнесе.
ПО – это только один из инструментов, необходимых для
реализации поставленной цели. При этом вы пока что знаете работу
этого конкретного бизнеса достаточно слабо, вы еще не успели
вникнуть во все нюансы. А потому уже в процессе внедрения
программного продукта вы можете сами понять, что нужно
воплотить дополнительные решения или запланированные
реализовать несколько иначе.» ([12])
А это изменение требований в ТЗ за очень дополнительные деньги.
Крючков А.В.
55

56.

Вопрос 4. Ввод в эксплуатацию ПС
Поэтому появились гибкие системы разработки ПО со стороны
разработчиков, которые стали продолжением выдвинутой в 80-е
годы прошлого века концепции А-программ (advanced). По идее
они должны были компенсировать недостатки интегрированных
систем, которые при внедрении всё равно должны быть
доработаны, скоростью внедрения изменений в ПС.
Любые изменения требований, не отражённых в ТЗ, требуют
фиксации в дополнительных соглашениях или приложениях к ТЗ.
Это – дополнительные действия, требующие оплаты. Поэтому при
внедрении скорость внесения изменений в ПО на этапе опытной
эксплуатации не может компенсировать затраты разработчика.
Крючков А.В.
56

57.

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

58.

Вопросы для закрепления материала
1. Перечислите действия, выполняемые при разработке технического проекта ПО
в соответствии с ГОСТ 19.102-77.
2. Что изучает теория алгоритмов в математике?
3. Что разрабатывают алгоритмисты?
4. Дайте определение термина «программа» в соответствии с ГОСТ 33707-2016.
5. Сравните термин «алгоритмизация» по ГОСТ Р 43.2.9-2019 с действиями
алгоритмистов на этапе технического проекта.
6. Кто такие операторы алгоритмизированных процессов и как они связаны с
системой «человек-информация»?
7. Перечислите к чему относятся типы алгоритмизированного представления
технических сведений.
8. Назовите альтернативные блок-схемам формы представления алгоритмов.
9. Для чего по сути формируются альбомы алгоритмов?
10. Дайте определение системы программирования.
Крючков А.В.
58

59.

Вопросы для закрепления материала
11. Можно ли считать спецификацию программы точной копией требований,
сформулированных в ТЗ?
12. Назовите основную причину трудностей, возникающих при внедрении новых
релизов разработанного ПО.
13. Назовите типы ошибок, которые приходится устранять программистам в ходе
отладки, при использовании СП, позволяющей создавать исполняемый файл.
Соотнесите их с 3 типами оценок при тестировании.
14. Дайте определения готовности, удовольствия и удовлетворённости по ГОСТ Р
ИСО/МЭК 25010-2015.
15. Для чего нужны архитектурные требования в ТЗ на программные системы?
16. Чем определяется «толщина» клиента в клиент-серверной архитектуре?
17. Чем опытная эксплуатация отличается от промышленной?
18. Чем завершается внедрение ПС в технологический процесс объекта ТЭК?
19. В чём отличие ввода в эксплуатацию ПС и его внедрения в терминах эпохи 2?
Крючков А.В.
59

60.

Литература
1. ГОСТ 33707-2016, Информационные технологии. Словарь: электронный ресурс: режим
доступа – https://allgosts.ru/35/020/gost_33707-2016?ysclid=lki4n9usah209502887
(21.07.2023).
2. ГОСТ Р 43.2.9-2019 Информационное обеспечение техники и операторской
деятельности. Язык операторской деятельности. Алгоритмизированное изложение
сведений в технической интегрально-лингвосемантизированной информации:
электронный ресурс: режим доступа – https://allgosts.ru/35/020/gost_r_43.2.9-2019
(21.07.2023).
3. ГОСТ Р 43.0.4-2009, Информационное обеспечение техники и операторской
деятельности. Информация в технической деятельности. Общие положения: электронный
ресурс: режим доступа – https://allgosts.ru/35/020/gost_r_43.0.42009?ysclid=lki5rnagoj932754370 (21.07.2023).
4. ГОСТ Р 43.0.3-2009, Информационное обеспечение техники и операторской
деятельности. Информация в технической деятельности. Ноон-технология в технической
деятельности. Общие положения: электронный ресурс: режим доступа –
https://allgosts.ru/35/020/gost_r_43.0.3-2009?ysclid=lki6b3m3jn571389095 (21.07.2023).
Крючков А.В.
60

61.

Литература
5. ГОСТ 19.102-77, Единая система программной документации. Стадии
разработки, Изд. Стандартов, 1985.
6. ГОСТ 19781-90 Обеспечение систем обработки информации программное.
Термины и определения: электронный ресурс: режим доступа –
https://allgosts.ru/01/040/gost_19781-90. (25.07.2023)
7. ГОСТ Р ИСО/МЭК 25010-2015, Информационные технологии. Системная и
программная инженерия. Требования и оценка качества систем и программного
обеспечения (SQuaRE). Модели качества систем и программных продуктов:
электронный ресурс: режим доступа – https://internetlaw.ru/gosts/gost/60038/?ysclid=lkjql8nbmz122567446. (25.07.2023).
8. ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011, Системная и программная
инженерия. Описание архитектуры: электронный ресурс: режим доступа –
https://internet-law.ru/gosts/gost/63426/?ysclid=lkjq6q5fcr500394310. (25.07.2023)
Крючков А.В.
61

62.

Литература
9. А.М. Вендров, Проектирование программного обеспечения экономических
информационных систем, М., Финансы и статистика, 2005.
10. Рекомендации по стандартизации Р 50.1.028-2001, Информационные
технологии поддержки жизненного цикла продукции. Методология
функционального моделирования, ИПК Издательство стандартов, 2003.
11. Стёпин Ю.П. Проектирование автоматизированных систем управления
производством в нефтяной и газовой промышленности. Базовые методы и модели:
Учебное пособие. – М.: Издательский центр РГУ нефти и газа (НИУ) им. И.М.
Губкина, 2021. – 339 с.
12. Кинзябулатов Рамиль. Внедрение программного продукта. Особенности работы
бизнес-консультанта. Часть I: электронный ресурс: режим доступа –
https://habr.com/ru/companies/trinion/articles/242747/. (27.07.2023)
Крючков А.В.
62

63.

Литература
7. ГОСТ Р 57700.37-2021, Компьютерные модели и моделирование.
Цифровые двойники изделий. Общие положения: электронный
ресурс: режим доступа – https://internetlaw.ru/gosts/gost/75810/?ysclid=lkccifkxv1484249312 (21.07.2023).
3. ГОСТ Р 57193-2016 Системная и программная инженерия.
Процессы жизненного цикла систем: электронный ресурс: режим
доступа – https://allgosts.ru/35/080/gost_r_571932016?ysclid=lk83o9n4es105119447. (17.07.2023)
9. ГОСТ Р 59276-2020. Системы искусственного интеллекта. Способы
обеспечения доверия: электронный ресурс: режим доступа –
https://internet-law.ru/gosts/gost/75406/?ysclid=lkceyfx3c1829320482
(21.07.2023).
Крючков А.В.
63