1. I* моделі (sd & sr)

2. Нормативні I* моделі

3. SSN – Software Supply Network

4. PDC – Product Deployment Context

1) і* - моделює соціальні аспекти екосистеми.

і* видає пріоритет соціальним суб'єктам, у яких є цілі, переконання, здібності і зобов'язання.

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

і* стимулювало значний інтерес до соціально-мотивованого підходу до моделювання і проектування, і призвело до низки цих розширень та адаптацій.

В і* центральна концептуальна конструкція моделювання є актор. Це абстракція, яка використовується для звернення до активних суб'єктів, здатних до самостійних дій. Акторами можуть бути люди, апаратне і програмне забезпечення, або їх комбінації. Актори за своєю суттю автономні - їх поведінка не є повністю керована, і вони не цілком пізнані.

В і*, зосереджуются на одному соціальному аспекті - добробут актора залежить від інших акторів. Актори залежать один від одного, при досягененні цілей, виконані завдання, ресурсозабезпечені.

У і* моделюванні, орієнтуємося на штучні властивості і відносини, а не реальну поведінку.

Існує два типи і* моделей:

• SD моделі (Модель стратегічних залежностей (SD) являє собою мережу спрямованих відносин залежностей між акторами. Зв’язок залежності вказує, що один актор (depender), якимось чином (dependum) залежить від іншого актора (dependee). )

• SR моделі (Стратегічна Rationale (SR) модель специфікує цілі, завдання, ресурси та м'які цілі для кожного учасника.)

2) Нормативні і*-моделі

і* орієнтований на взаємодію норм, акторів і цілей називається нормативною і*.

“Норма” – засіб для представлення стандартів поведінки, який діє як абстракція для деяких видів предписаній– правила, закони, регулятори, стандарти тощо.

В і* норми представляють в трикутнику зі зв'язками від джерела норми до адресата, тобто кому назначено цю норму. Норма може мати власну модель – схему. Схема норми – це поведінковий шаблон, в якому вказуються шляхи дій, цілі, принципи, відповідно до яких повинен діяти адресат, щоб виконати норму. Тому дії адресата норми у вигляді схеми повинні відповідати нормі. Норми можуть по різному впливати на акторів.

3) SSN (Software Supply Network) являє ряд пов'язаних між собою областей, таких як програмне забезпечення, апаратне забезпечення та обслуговування організацій, що співпрацюють для задоволення вимог ринку. компонентами та забезпечують їх почерговий перегляд з різних мережевих локацій.

4) PDC (Product Deployment Context) забезпечує швидкий огляд архітектури та залежностей програмного продукту в своєму працюючому навколишньому середовищі. Деталі, представлені PDC, показують ієрархію між різними продуктами і і компонентами та забезпечують їх почерговий перегляд з різних мережевих локацій.

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

Після успішного проведення тестування програмний продукт вводиться в промислову експлуатацію. Реалізація даного етапу зазвичай означає успішне впровадження. Закінчення робіт оформляється протоколом введення в промислову експлуатацію.

модель впровадження ПЗ в систему бухгалтерського обліку підприємства, яка представлена на рис. 4.

Рис. 4. Поетапна модель впровадження ПЗ в систему бухгалтерського обліку підприємств

+26.5.Розгляньте наступні рядки 64-бітного програмного коду, знайдіть та поясніть помилку, перепишіть код для виправлення помилки:

size_t Count = BigValue;

for (unsigned Index = 0; Index != Count; Index++)

{ ... }

Поскольку значения переменной  Index  лежат в диапазоне [0..UINT_MAX], то условие «Index < Count» всегда выполняется, что и приводит к бесконечному циклу.

size_t Count = BigValue; for (size_t Index = 0; Index != Count; Index++) { ... }

ВАРІАНТ № 27

27.1. Зелені інформаційні системи.

27.2. Методи обчислення арифметичних виразів, які представлені у зворотному польському запису.

27.3. Рівні абстракції дослідження програмного забезпечення.

27.4.Описати послідовність дій для налаштування звіту в TFS.

27.5.На прикладі програмного забезпечення перерахуйте та розрите зміст нормативно-технічних документів, які застосовуються при регламентуванні дій пов’язаних з впровадженням і експлуатацією програмного забезпечення.

+27.1. Зелені інформаційні системи.

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

В информационных системах снизить потребление электроєнергии можно двумя путями:

• уменьшая электропотребление за счет совершенствования конструкций компонентов аппаратной части информационной системы;

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

Реализация экологических принципов для аппаратной части рассматривается в трех аспектах :

• энергосбережение;

• ликвидация компонентов информацион-ных систем;

• центры данных.

При этом озеленению подлежат все процессы жизненного цикла информационных систем:

1.Зеленое проектирование (проектировать энергетически эффективные и не влияющие на окружающую

среду продукты и процессы)

2.Зеленое производство (Производить компоненты информационных систем с минимальным влиянием на окружающую среду)

3.Зеленое использование (Уменьшать потребление энергии компонентами и вредное влияние информационных систем)

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

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

При создании и использовании зеленых информационных систем и технологий следует руководствоваться тремя принципами устойчивого развития:

98. экологическая эффективность,

99. экологическая справедливость,

100. экологическая результативность.

Эко-эффективность - следуя принципу нужно в деятельности применять меньше методов и средств, которые вредят природе и неэффективно используют невосста навливаемые ресурсы.

Эко-справедливость - следуя принципу нужно равно распределять ресурсы между живущим и следующими поколениями.

Эко-результативность - следуя принципу надо полностью прекращать негативне влияние на окружающую среду.

+-27.2. Методи обчислення арифметичних виразів, які представлені у зворотному польському запису.

Звичною формою запису виразів є інфіксна, коли знак бінарної операції записують між позначеннями операндів цієї операції, наприклад, a + b. Розглянемо запис знаків операцій після позначень операндів, тобто постфіксний запис, наприклад, a b +. Такий запис має також назву зворотного польського,

Зворотна польська нотація (ОПН) - форма запису математичних виразів, в якій операнди розташовані перед знаками операцій.

Особенности обратной польской записи следующие:

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

• В отличие от инфиксной записи, невозможно использовать одни и те же знаки для записи унарных и бинарных операций. Так, в инфиксной записи выражение 5 * (-3 + 8) использует знак «минус» как символ унарной операции (изменение знака числа), а выражение (10 - 15) * 3 применяет этот же знак для обозначения бинарной операции (вычитание). Конкретная операция определяется тем, в какой позиции находится знак. Обратная польская запись не позволяет этого: запись 5 3 - 8 + * (условный аналог первого выражения) будет интерпретирована как ошибочная, поскольку невозможно определить, что «минус» после 5 и 3 обозначает не вычитание; в результате будет сделана попытка вычислить сначала 5 - 3, затем 2 + 8, после чего выяснится, что для операции умножения не хватает операндов. Чтобы всё же записать это выражение, придётся либо переформулировать его, либо ввести для операции изменения знака отдельное обозначение, например, «±»: 5 3 ± 8 + *.

• Так же, как и в инфиксной нотации, в ОПН одно и то же вычисление может быть записано в нескольких разных вариантах. Например, выражение (10 - 15) * 3 в ОПН можно записать как 10 15 - 3 *, а можно — как 3 10 15 - *

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

Например, рассмотрим вычисление выражения 7 2 3 * - (эквивалентное выражение в инфиксной

нотации: 7-2*3).

1.Первый по порядку знак операции - «*», поэтому первой выполняется операция умножения над операндами 2 и 3 (они стоят последними перед знаком). Выражение при этом преобразуется к виду 7 6 - (результат умножения — 6, — заменяет тройку «2 3 *»).

2.Второй знак операции — «-». Выполняется операция вычитания над операндами 7 и 6.

3.Вычисление закончено. Результат последней операции равен 1, это и есть результат вычисления выражения.

+27.3. Рівні абстракції дослідження програмного забезпечення.

Абстракція — одна з основних операцій мислення, а також метод наукового дослідження, що полягає в тому, що суб’єкт, відокремлюючи які-небудь ознаки об’єкту, що вивчається, відволікається від інших, не враховуються його неістотні сторони і ознаки.

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

Абстракція намагається зменшити фактор детальності, так що програміст може зосередити увагу на декількох концепціях одночасно.

Рівні абстракції:

• програмний

• шаблонний (рівень паттернів)

• графів

• архітектурний

• даних

• прикладний

• бізнес

Програмний рівень:

• Окремі вирази

• Змінні

• Значення

• Типи процедури

Шаблонний рівень

Шаблони (паттерни) – повторяємо архітектурна конструкція, що представляє собою вирішення проблеми проектування в рамках деякого часто виникаючого контексту (абстрактна фабрика, компонувальник та інш.)

Стилі (процедурний, функціональний, логічний, об’єктно-орієнтований)

Процедурне програмування – програмування, при якому програма представляє собою послідовність операторів. Використовується в мовах високого рівня Basic, Fortran та інш.

Функціональне програмування – програмування, при якому програма представляє собою послідовність викликів функцій. Використовується в Lisp та інш.

Логічне програмування – програмування, при якому програма представляє собою сукупність визначення співвідношень між об’єктами. Використовується в мовах Prolog та інш.

Об’єктно-орієнтоване програмування – це програмування, при якому основою програми є об’єкт, що представляє собою сукупність даних і правил їх перетворення. Використовується в мовах Turbo-Pascal, C++ та інш.

Рівень графів

• зв’язки між процедурами

• зміни станів

Архітектурний рівень

• архітектурні стилі (клієнт-серверна модель, подійна архітектура, пошуково-орієнтована та інш);

• методології

• інтерфейси

Рівень даних

• Структури даних

• Потоки даних

• Атрибути баз даних

Прикладний рівень

• Обмін даними із зовнішнім середовищем/платформою

Бізнес рівень

• Концепція бізнес-домену

• Бізнес-умови/правила

• Їхня програмна реалізація

+27.4.Описати послідовність дій для налаштування звіту в TFS.

Задачи

• Создать проект отчетов в Visual Studio.

• Настроить существующий отчет согласно своим нуждам.

• Опубликовать новый отчет на сервере отчетов.

Порядок операций

• Шаг 1 — создание нового проекта отчетов.

• Шаг 2 — экспорт отчета.

• Шаг 3 — создание источников данных.

• Шаг 4 — добавление отчета в проект.

• Шаг 5 — редактирование отчета.

• Шаг 6 — развертывание отчета на Team Foundation Server.

• Шаг 7 — тестирование отчета

Шаг 1 — создание нового проекта отчетов

1. В Visual Studio откройте меню File, выберите команду New и щелкните Project.

2. Выберите тип Business Intelligence Project.

3. Выберите шаблон Report Server Project.

4. Задайте имя и расположение проекта. Затем щелкните OK.

Шаг 2 — экспорт отчета

Отчет, который требуется настроить, экспортируется с портала проекта, чтобы затем импортировать его в новый проект отчетов. Выполните следую-щие действия, чтобы экспортировать отчет:

1. Щелкните правой кнопкой свой командный проект и выберите Show Project Portal.

2. На панели Quick Launch левой части веб-сайта портала щелкните Reports.

3. Выберите отчет, который хотите настраивать.

4. Щелкните Properties.

5. Выберите Edit.

6. Сохраните файл .rdl отчета в папку проекта отчетов, который был создан в шаге 1.

Шаг 3 — создание источников данных

Чтобы редактировать и публиковать настроенный отчет, необходимо доба-вить источники данных для хранилища данных Team Foundation Server и OLAP-куб. После добавления этих источников данных в проект Visual Studio отчет может закачивать данные с сервера.

Создание источника данных хранилища

1. В окне Visual Studio Solution Explorer щелкните правой кнопкой Shared Data Sourcesи выберите команду Add New Data Source.

2. На вкладке Generalвведите TfsReportDSв текстовое поле Name.

3. В списке Typeвыберите Microsoft SQL Server.

4. Щелкните Edit.

5. Введите имя сервера уровня данных.

6. Выберите базу данных TFSWarehouse.

7. Дважды щелкните ОК, чтобы добавить источник данных.

Создание источника данных OLAP

1. В окне Visual Studio Solution Explorer щелкните правой кнопкой Shared Data Sourcesи выберите команду Add New Data Source.

2. На вкладке Generalвведите TfsOlapReportDSв поле Name.

3. В списке Typeвыберите Microsoft SQL Server Analysis Services.

4. Щелкните Edit.

5. Введите имя сервера уровня данных.

6. Выберите базу данных TFSWarehouse.

7. Дважды щелкните ОК, чтобы добавить источник данных.

Шаг 4 — добавление отчета в проект

Теперь, когда в проект добавлены источники данных, можно импортировать отчет, экспортированный на шаге 2:

1. В Solution Explorerщелкните правой кнопкой Reports, выберите Add и затем щелкнитеExisting Item.

2. Перейдите к файлу .rdl, экспортированному на шаге 2.

Шаг 5 — редактирование отчета

Добавив отчет в проект, внесите в него коррективы и настройте соответс-твенно своим нуждам. Чтобы открыть отчет для редактирования, дважды

щелкните его в Solution Explorer. Теперь его можно менять следующим об-разом:

менять операторы запросов в Data Pane;

перетаскивать новые меры или элементы в Data Pane;

менять разметку отчета в Layout Pane.

Шаг 6 — развертывание отчета на Team Foundation Server

Внеся изменения в отчет, разверните его на портале отчетов командного проекта:

101. В Solution Explorer щелкните правой кнопкой проект отчетов и выберите Properties.

102. Убедитесь, что атрибуту OverwriteDataSources присвоено значение false.

103. Измените значение TargetDataSourceFolderсогласно имени своего командного проекта, например: TargetDataSourceFolder = TestProject

104. Измените значение TargetReportFolderсогласно имени своего команд-ного проекта, например:TargetReportFolder = TestProject

105. Присвойте параметру TargetServerURL значение http://<имя сервера уровня данных>/reportserver, например: TargetServerURL = http://tfsrtm/reportserver

106. Щелкните OK.

107. В Solution Explorer щелкните правой кнопкой файл .rdl и выберите Deploy.

108. Посмотрите на Output Pane, чтобы убедиться в успешности операции.

109. Шаг 7 — тестирование отчета

110. Опубликовав отчет на сервере отчетов своего командного проекта, протес-тируйте его, чтобы убедиться в успешности развертывания:

111. 1. В Team Explorerразверните узел своего командного проекта, щелкните правой кнопкой Reportsи выберите команду Show Report Site.

112. 2. На сайте отчетов выберите созданный отчет.

113. 3. Убедитесь, что он выглядит так, как ожидалось.

+***27.5.На прикладі програмного забезпечення перерахуйте та розрите зміст нормативно-технічних документів, які застосовуються при регламентуванні дій пов’язаних з впровадженням і експлуатацією програмного забезпечення.

Описать применительно к своему проекту всё то, что на картинке? Кто и как это делает в системе, на которой делает пример.

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

===========теория

Перед впровадженням програмний продукт потребує документації — опису можливостей, посібників користувача, системи допомоги. Після впровадження програмного забезпечення, що для програмних продуктів вимагає маркетингу, системи дистрибуції, реклами тощо, програмне забезпечення потребує підтримки. Необхідність у підтримці виникає внаслідок швидкого розвитку комп'ютерів, що зумовлює необхідність взаємодії програмного продукту з іншими, новішими програмами і новою матеріальною базою. Часто підтримка нових можливостей забезпечується випуском нових версій програмного продукту.

• Информационные системы эксплуатации и поддержки.

• Процедуры и процессы.

• Базы знаний, отчеты, журналы протоколов.

• Версии проектных документов, массивы данных и программный код, разработанные во время проекта.

• Отчет о завершении проекта.

• Окончательные версии всех проектных документов.

• Показатели удовлетворенности заказчика и потребителей.

• Описание последующих шагов.

ВАРІАНТ № 28

+28.1.Функціональне тестування програмного забезпечення.

Функціональне тестування є частиною його тестування чорної скриньки.

Завданням функціонального тестування є перевірка відповідності програми своїм зовнішнім специфікаціям (виявлення невідповідностей між реальною поведінкою реалізованих функцій і очікуваною поведінкою відповідно до специфікації і вимог).

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

Функціональне тестування застосовується тільки коли ПЗ вже створене, тобто на останніх етапах життєвого циклу ПЗ.

Найпоширенішими видами функціонального тестування є методи випадкового тестування, еквівалентного розбиття й аналізу граничних умов.

До задач функціонального тестування належать:

• ідентифікація множини функціональних вимог;

• ідентифікація зовнішніх функцій і побудова послідовностей функцій відповідно до їхнього використання в ПС;

• ідентифікація множини вхідних даних кожної функції і визначення областей їхньої зміни;

• побудова тестових наборів і сценаріїв тестування функцій;

• виявлення і подання усіх функціональних вимог за допомогою тестових наборів і проведення тестування помилок у програмі і при взаємодії із середовищем.

Тести, створювані за проектною інформацією, пов'язані зі структурами даних, алгоритмами, інтерфейсами між окремими компонентами і застосовуються для тестування компонентів і їхніх інтерфейсів. Основна мета – забезпечення повноти і погодженості реалізованих функцій і інтерфейсів між ними.

В основу комбінованого методу «чорної скриньки» і «білої скриньки» покладено розбивку вхідної області функції на підобласті виявлення помилок. Підобласть містить у собі однорідні елементи, які обробляються коректно або некоректно. Для тестування підобласті застосовується виконання програми на одному з елементів цієї області.

Передумови функціонального тестування:

• коректне оформлення вимог і обмежень до якості ПС;

• коректний опис моделі функціонування ПС у середовищі експлуатації замовника;

• адекватність моделі ПС заданому класу.

Одні з найпоширеніших видів функціональних тестів:

• Функціональне тестування (Functional testing).

• Тестування безпеки (Security and Access Control Testing) - стратегія тестування, що використовується для перевірки безпеки системи, а також для аналізу ризиків, пов'язаних із забезпеченням цілісного підходу до захисту програми, атак хакерів, вірусів, несанкціонованого доступу до конфіденційних даних. Тестування безпеки може виконуватися як автоматизовано так і в ручну, включаючи перевірку як позитивних, так і негативних тестових випадків.

• Тестування взаємодії (Interoperability Testing) - це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає в себе тестування сумісності (compatibility testing) та інтеграційне тестування (integration testing).

+28.2.Сценарії ведення проекту. Сценарії розгалуження і злиття. Призначення

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

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

Сценарии, в которых может понадобиться создавать ветви и выполнять слияния:

• Ветвь разработки должна быть создана при наличии постоянных проблем с дефектными сборками для изолирования параллельных процессов разработки.

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

• Не следует использовать ветвление, если в нем нет крайней необходимости. Ветвление требует дополнительного обслуживания каталога исходного кода и выполнения задач по слиянию. Для большинства групп разработки, которые занимаются созданием бизнес-приложений и имеют короткие циклы выпуска новых версий, ветвления не требуется. Группам разработки, реализующим более длинные циклы выпуска, таким как Независимые производители ПО (Independent Software Vendors, ISV), которые создают «коробочные» приложения, скорее всего, придется прибегнуть к ветвлению в своем процессе разработки.

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

Типовые сценарии на практике:

Сценарий 1 – Нет ветвления.

Сценарий 2 – Ветвление для выпуска версии.

Сценарий 3 – Ветвление для обслуживания.

Сценарий 4 – Ветвление для разработки функциональной возможности.

Сценарий 5 – Ветвление для изоляции группы.

Пример

Сценарий 2 - «Ветвление для выпуска версии»

В этом сценарии группа создает ветвь для стабилизации версии и, после выпуска версии ПО, объединяет ветвь этой версии с основным деревом исходного кода:

My Team Project

Main → Главная ветвь интеграции

Source

Releases

Release 1 → Ветвь выпускаемой версии

Source

+28.3.Безвідходні та ресурсозберігаючі технології.

Ресурсозберігаюче виробництво – це виробництво і реалізація продуктів з мінімальною витратою речовин і енергії на всіх етапах виробничого циклу і з найменшим впливом на людину та природні системи. Таке виробництво — запорука сталого розвитку. Основою ресурсозберігаючого виробництва є ресурсозберігаючі технології.

Розглянемо існуючі ресурси інженерії програмного забезпечення (принципи, процеси, конструкції), які відіграють важливу роль і можуть використовуватися як основа для побудови ресурсозберігаючих і безвідходних технологій розробки і супроводження програмного забезпечення (табл. 1).

Методи, принципи, конструкції екологічного програмного забезпечення

№ з/п	Методи/ ресурси	Програмне (процедурне) програмування	Об’єктно-орієнтоване програмування	Модульне програму-вання
1	Конструкції	Підпрограма (закрита, відкрита), шаблон	Клас (С, С++)	Модуль (Модула 2,3), пакет (Ada)
2	Принципи реалізації конструкцій	Параметризація	Поліморфізм, наслідування, класифікація	Роздільна компіляція
3	Принципи використання конструкцій	Процедурна абстракція, абстракція виконання, шаблонування	Класифікація	Композиція
4	Фундаментальна абстракція	Абстрактний тип даних

Першою такою конструкцією була підпрограма, яку розглядали як засіб скорочення тексту програми. Гнучкість конструкції забезпечувала параметризація. Незабаром погляд на підпрограму почав змінюватися, і її стали розглядати, як засіб структурної організації програм.

Пристосування програми до очікуваних змін постановки завдання або супроводження зводилась до заміни тіла підпрограм або до зміни значень деяких фактичних параметрів у зверненні до підпрограм.

Тому, підпрограми застосовувалися як процедурні абстракції, абстракції виконання (закриті підпрограми) або шаблони (відкриті підпрограми). В якості застосування методу підпрограми використовувалося підпрограмне (процедурне) програмування. Пізніше, слідуючи прагненню поліпшити конструкцію для реалізації абстрактних типів даних були створені модуль і клас.

У 1984 році при розгортанні досліджень, пов'язаних з повторним використанням програмного забезпечення зверталася увага на те, що з часом кількість принципово нових застосувань обчислювальних машин зменшується. Це свідчило про те, що супроводжуване програмне забезпечення, яке згодом стали називати успадкованим (або наслідуваним), містило досвід, і його слід було повторно використовувати при створенні нового програмного забезпечення. Завдяки цьому життєвий цикл програмного забезпечення був розширений додатковими процесами (рис. 1).

Рис. 1. Розширення життєвого циклу ПЗ

З одного боку, він був доповнений доменним аналізом, мета якого — шляхом аналізу досвіду, накопиченого в домені будувати повторно використовувані для вирішення застосування у розробці нового програмного забезпечення. З іншого боку в життєвий цикл ПЗ в контексті фази ліквідації були введені процеси, які пов'язані з утилізацією програмного забезпечення (рис. 2)

Рис. 2. Склад фази ліквідації

Реалізація процесів утилізації призвела до появи зворотного (реверсивної) інженерії програмного забезпечення, з'єднання якої з прямою інженерією дало реінженерію і дозволило в екологічному аспекті розглядати розробку і супровід програмного забезпечення як його кругообіг.

Рис. 3. Кругообіг ПЗ

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