4 Процесс эксплуатации
Процесс эксплуатации состоит из работ и задач оператора. Процесс охватывает эксплуатацию программного продукта и поддержку пользователей в процессе эксплуатации. Так как эксплуатация программного продукта входит в эксплуатацию системы, работы и задачи данного процесса связаны с системой.
Оператор управляет процессом эксплуатации на проектом уровне в соответствии с процессом управления (подраздел 7.1). который конкретизируется в данном процессе: определяет инфраструк¬туру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2); адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение Л) и управляет процессом эксплуатации на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если оператор является поставщи¬ком программной услуги, то оператор выполняет также процесс поставки (подраздел 5.2).
Список работ. Данный процесс состоит из следующих работ:
1) подготовка процесса;
2) эксплуатационные испытания;
3) эксплуатация системы;
4) поддержка пользователя.
5 Процесс сопровождения
Процесс сопровождения состоит из работ и задач, выполняемых персоналом сопровождения. Данный процесс реализуется при изменениях (модификациях) программного продукта и соответ¬ствующей документации, вызванных возникшими проблемами или потребностями в модернизации или настройке. Целью процесса является изменение существующего программного продукта при сохранении его целостности. Данный процесс охватывает вопросы переносимости и снятия программного продукта с эксплуатации. Процесс заканчивается снятием программного продукта с эксплуатации.
Работы, выполняемые в данном процессе, характерны для процесса сопровождения, однако в данном процессе могут испольюваться другие процессы, определенные в настоящем стандарте. Если в данном процессе используется процесс разработки, то персонал сопровож¬дения выступает в роли разработчика.
Персонал сопровождения управляет процессом сопровождения на проектном уровне в соот¬ветствии с процессом управления, который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструк¬туры; адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет процессом сопровождения на организационном уровне в соответствии с процессами усовершенствования и обучения. Если персонал сопровождения является поставщиком услуги по сопровождению, он реализует процесс поставки.
Список работ. Данный процесс состоит из следующих работ:
1) подготовка процесса;
2) анализ проблем и изменений;
3) внесение изменений;
4) проверка и приемка при сопровождении:
5) перенос:
6) снятие с эксплуатации.
- Вспомогательные процессы жизненного цикла
В дампом разделе определены следующие вспомогательные процессы жизненного цикла:
1) процесс документирования;
2) процесс управления конфигурацией:
3) процесс обеспечения качества:
4) процесс верификации;
5) процесс аттестации;
6) процесс совместного анализа;
7) процесс аудита:
8) процесс решения проблем.
Ответственность за работы и задачи вспомогательного процесса несет организация, выпол¬няющая данный процесс. Данная организация гарантирует реальность существования и функцио¬нальные особенности конкретного процесса.
Данная организация организует и выполняет управление вспомогательным процессом на проектном уровне в соответствии с процессом управления: определяет инфраструк¬туру для данного процесса в соответствии с процессом создания инфраструктуры; адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет вспомогательным процессом на организационном уровне в соответствии с процес¬сами усовершенствования и обучения. В качестве методов обеспе¬чения качества могут быть использованы: совместные анализы, аудиторские проверки, верификация и аттестация.
+13.3.Наведіть приклад конструкції програмного забезпечення, які використовують в безвідходному та ресурсозберігаючому виробництві програмного забезпечення.
Ресурсозберігаюче виробництво – це виробництво і реалізація продуктів з мінімальною витратою речовини та енергії на всіх етапах виробничого циклу і з найменшою дією на людину та природні системи.
Основою ресурсозберігаючого виробництва є ресурсозберігаючі технології.
Існуючі ресурси інженерії програмного забезпечення (принципи, процеси, конструкції) відіграють важливу роль і можуть використовуватися як основа для побудови ресурсозберігаючих і безвідходних технологій розробки і супроводу програмного забезпечення.
Першою такою конструкцією була підпрограма, яку розглядали як засіб скорочення тексту програми. Гнучкість конструкції забезпечувала параметризація. Незабаром погляд на підпрограму почав змінюватися, і її стали розглядати, як засіб структурної організації програм.
Пристосування програми до очікуваних змін постановки завдання або супроводження зводилась до заміни тіла підпрограм або до зміни значень деяких фактичних параметрів у зверненні до подпрограммам. Тому, підпрограми застосовувалися як процедурні абстракції, абстракції виконання (закриті підпрограми) або шаблони (відкриті підпрограми).
В якості застосування методу підпрограми використовувалося підпрограмне (процедурне) програмування.
З метою поліпшення конструкцій для реалізації абстрактних типів даних були створені модуль і клас (модульне та об’єктно-орієнтоване програмування відповідно).
Методи, принципи, конструкції екологічного ПЗ
№ з/п |
Методи/ ресурси |
Програмне (процедурне) програмування |
Об’єктно-орієнтоване програмування |
Модульне програмування |
1 |
Конструкції |
Підпрограма (закрита, відкрита), шаблон |
Клас (С, С++) |
Модуль (Модула 2,3), пакет (Ada) |
2 |
Принципи реалізації конструкцій |
Параметризація |
Поліморфізм, наслідування, класифікація |
Роздільна компіляція |
3 |
Принципи використання конструкцій |
Процедурна абстракція, абстракція виконання, шаблонування |
Класифікація |
Композиція |
4 |
Фундаментальна абстракція |
Абстрактний тип даних |
||
z
+13.4.Показати, що ланцюг –1/18 належить мові, що задається граматикою
G4={T, N, P, D}:
T={0, .., 9, +, –, /} N={D, G, P, ЦИФРА} Правила P D ::= G | +G | –G G ::= P | P/P P ::= ЦИФРА | ЦИФРА P ЦИФРА ::= 0 | 1 . . . | 9
шляхом побудови дерева виводу.
+***13.5.Розгляньте наступну ситуацію: у Вас є застаріле банківське програмне забезпечення, що виконує функції біллінгу. Для нього повністю відсутня документація. Вам поставили завдання виконати повторну інженерію цього ПЗ з метою перенесення його на сучасну апаратну платформу, причому нова версія має працювати так само чітко і надійно, як і застаріла версія. Визначте набір процесів, підходів, засобів (інструментів) та тестів для вирішення поставленого завдання.
Изменение документации, в зависимости от исходного состояния проекта и новых требований к документированию, может затрагивать разные виды спецификаций проекта. На рис. 3 показана модель восстановления и переработки спецификаций проекта, в которой можно выделить процессы двух основных видов: редокументирование и обратная инженерия [2]. Редокументирование реализует изменения формы представления спецификаций определенного этапа разработки, без использования спецификаций других этапов. Обратная инженерия реализует восстановление или изменение (путем реализации процессов прямой инженерии) спецификаций определенного этапа разработки на основе спецификаций других этапов.
Артефакты, получаемые в результате проектирования ПО, создаются в рамках определенной системы (модели) проектирования. В ней можно выделить следующие основные элементы: парадигму проектирования, языки специфицирования, инструментальные средства проектирования и документирования. Сейчас одним из наиболее совершенных и перспективных процессов разработки ПО-унифицированный процесс разработки (Rational Unified Process - RUP) [5]. В RUP проектирование основано на объектно-ориентированной парадигме, а для специфицирования проекта и его результатов используется язык Unified Modeling Language (UML) [6]. В настоящее время RUP поддерживается семейством продуктов IBM Rational [7]. В рамках RUP, при выполнении рабочих процессов разрабатывается ряд моделей, которые представляются с использованием языка UML. К основным относят следующие модели [5, 7]: требований; анализа, проектирования, развертывания, реализации, тестирования. Основываясь на анализе фаз и рабочих процессов RUP можно распределить эти модели по видам спецификаций (рис.1) следующим образом [5]:
− требований – модель требований;
− проектные – модели анализа и проектирования;
− реализации – модели развертывания, реализации и тестирования.
Очевидно, что для эффективной переработки исходной документации проекта на соответствие моделям RUP необходимо провести предварительное сопоставление их содержания. В таблице приведено сопоставление моделей и артефактов RUP [5, 9] c видами исходных документов проектов ПО, определяемых стандартом [8]. Сопоставление проведено на основе анализа их назначения, семантики и содержания. Кроме того, в таблице приведены типы процессов, обеспечивающие переработку содержимого исходных документов, и исполнители, в качестве которых могут выступать эксперты или соответствующие CASE-инструменты [10]. Сопоставление моделей и артефактов RUP документам стандарта.
1. Начать нужно с определения того, что у нас есть по программе, исходные тесты, БД. Зафиксировать текущее состояние системы для сверения с результатами последующих изменений.
2. Работы по описанию архитектур начинаются фактически на начальном этапе, когда определяется состав оборудования и стандартное программное обеспечение (ПО), необходимые для инсталляции и запуска существующей зафиксированной системы. Тем самым фактически определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры представляются в нотации UML и при необходимости дополняются текстовыми описаниями. Поостренные архитектурные модели в процессе реинжиниринга будут уточняться и дополняться.
3. Построение функциональной модели, диаграммы вариантов использования
4. Анализ требований к системе (функциональных и нефункциональных)
5. На основе полученных спецификаций провести проектирование системы.
6. Провести реализацию системы
7. Провести тестирование системы методами белого ящика и черного ящика, для проверки связей между компонентами и правильности интеграции компонентов, провести модульное тестирование, сверяя результаты с прошлой системой
==============
ВАРІАНТ № 14
Безвідходне та ресурсозберігаюче виробництво програмного забезпечення.
Типи робочих елементів шаблону процесуMSFAgile
Перерахуйте та розкрийте призначення моделей, які застосуються при впровадженні програмного забезпечення.
Розгляньте наступні рядки коду та напишіть простий модульний тест для перевірки правильності значень, які повертає клас Calculator:
public class Calculator
{
bool _isDirty;
string _operation;
decimal _state;
public decimal Display { get; private set; }
public void Enter(decimal number)
{ _state = number;
_isDirty = true; }
public void PressPlus()
{ _operation = "+";
if (_isDirty) Calculate(); }
public void PressEquals()
{ if (_isDirty) Calculate(); }
void Calculate()
{ switch (_operation)
{ case "+":
Display += _state;
break; }
_isDirty = false; }
}
Показати, що ланцюг –123 належить мові, що задається граматикою G2={T,N, P, I}:
T={0, .., 9, +, –} N={I, P, ЦИФРА} Правила P I ::= P | +P | –P P ::= ЦИФРА | ЦИФРА P ЦИФРА ::= 0 | 1 . . . | 9