Master’s thesis in software engineering – object, subject, contents of research
Nowadays scientific researches In Ukraine are based on formulating the goals of research, us- ing the concept of object and subject of research. Moreover, as time has shown, this is an important stage of work on which the effectiveness of the study depends. Both the total use of a software in differen...
Gespeichert in:
| Datum: | 2022 |
|---|---|
| 1. Verfasser: | |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2022
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/497 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-497 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/4f/e91f29e67b2e9144b5f0e03bde314e4f.pdf |
| spelling |
pp_isofts_kiev_ua-article-4972023-01-15T19:39:00Z Master’s thesis in software engineering – object, subject, contents of research Дисертація магістрів з інженерії програмного забезпечення - об′єкт, предмет, зміст досліджень Sydorov, M.O. software engineering; education; master’s research; scientific and experimental research methods UDC 502:004.45 (075.8) інженерія програмного забезпечення; навчання; магістерські дослідження; науково-експериментальні методи досліджень УДК 502:004.45 (075.8) Nowadays scientific researches In Ukraine are based on formulating the goals of research, us- ing the concept of object and subject of research. Moreover, as time has shown, this is an important stage of work on which the effectiveness of the study depends. Both the total use of a software in different arias of life and improvement of software engineering prepare better conditions for this stage of the dissertation research. Modern software engineering uses scientific research methods that should be used to perform dissertation research. The purpose of this article is the following: to provide recommendations for the formulation of the object and subject of the master’s thesis. Special phocus is made on specialization in the software engineering fundamentals. It also aimed at describing the scientific methods of evidence-based research in the master’s thesis. It pays attention to the results presentation. These points are considered in the context of the conditions that have developed in education and the relevant problems that have arisen in the Universities′ curriculum. There are some problems in choosing the topics of master′s thesis. The one is objective in nature and arises from the combination of the domain of software engineering with application domains in a context of specialization. The article is aimed at masters in software engineering and their supervisors.Prombles in programming 2022; 2: 22-36 На відміну від закордонних університетів, в Україні протягом багатьох років склалася й існує практика формулювання мети дослідження, застосовуючи поняття об’єкта і предмета дослідження. І це, як показав час, важливий етап роботи, від виконання якого залежить результативність дослідження. Загальне, тотальне проникнення програмного забезпечення в життя з одного боку, а з іншого - поява спеціалізацій інженерії програмного забезпечення значно ускладняють умови виконання цього етапу магістерського дисертаційного дослідження. Окрім цього, в інженерії програмного забезпечення застосовуються наукові методи досліджень, які доцільно мати на увазі і використовувати для виконання магістерського дисертаційного дослідження. Тому актуальними є питання щодо формулювання об’єкта і предмета досліджень та застосування доказових методів їх виконання. Метою цієї статті було надання рекомендації на основі фундаментальних положень інженерії програмного забезпечення щодо формулювання об’єкта і предмета магістерської дисертації зі спеціалізації в контексте інженерії програмного забезпечення. А також, вказати на застосування в магістерської дисертації наукових методів доказових досліджень і звернути увагу на оформлення результатів. Досягнення мети розглядається в контексті причин і умов, які історично склалися в навчанні, і відповідних проблем, що виникли в навчальних планах, виборі тем і змісту досліджень магістерських дисертацій. Одна з причин, яка має об’єктивний характер, виникає за сполучення домену інженерії програмного забезпечення з прикладними доменами, що є основою відповідної спеціалізації. Стаття розрахована на магістрів зі спеціалізацій інженерії програмного забезпечення та їхніх наукових керівників.Prombles in programming 2022; 2: 22-36 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2022-09-26 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/497 10.15407/pp2022.02.022 PROBLEMS IN PROGRAMMING; No 2 (2022); 22-36 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2022); 22-36 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2022); 22-36 1727-4907 10.15407/pp2022.02 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/497/495 Copyright (c) 2022 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2023-01-15T19:39:00Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
software engineering education master’s research scientific and experimental research methods UDC 502:004.45 (075.8) |
| spellingShingle |
software engineering education master’s research scientific and experimental research methods UDC 502:004.45 (075.8) Sydorov, M.O. Master’s thesis in software engineering – object, subject, contents of research |
| topic_facet |
software engineering education master’s research scientific and experimental research methods UDC 502:004.45 (075.8) інженерія програмного забезпечення навчання магістерські дослідження науково-експериментальні методи досліджень УДК 502:004.45 (075.8) |
| format |
Article |
| author |
Sydorov, M.O. |
| author_facet |
Sydorov, M.O. |
| author_sort |
Sydorov, M.O. |
| title |
Master’s thesis in software engineering – object, subject, contents of research |
| title_short |
Master’s thesis in software engineering – object, subject, contents of research |
| title_full |
Master’s thesis in software engineering – object, subject, contents of research |
| title_fullStr |
Master’s thesis in software engineering – object, subject, contents of research |
| title_full_unstemmed |
Master’s thesis in software engineering – object, subject, contents of research |
| title_sort |
master’s thesis in software engineering – object, subject, contents of research |
| title_alt |
Дисертація магістрів з інженерії програмного забезпечення - об′єкт, предмет, зміст досліджень |
| description |
Nowadays scientific researches In Ukraine are based on formulating the goals of research, us- ing the concept of object and subject of research. Moreover, as time has shown, this is an important stage of work on which the effectiveness of the study depends. Both the total use of a software in different arias of life and improvement of software engineering prepare better conditions for this stage of the dissertation research. Modern software engineering uses scientific research methods that should be used to perform dissertation research. The purpose of this article is the following: to provide recommendations for the formulation of the object and subject of the master’s thesis. Special phocus is made on specialization in the software engineering fundamentals. It also aimed at describing the scientific methods of evidence-based research in the master’s thesis. It pays attention to the results presentation. These points are considered in the context of the conditions that have developed in education and the relevant problems that have arisen in the Universities′ curriculum. There are some problems in choosing the topics of master′s thesis. The one is objective in nature and arises from the combination of the domain of software engineering with application domains in a context of specialization. The article is aimed at masters in software engineering and their supervisors.Prombles in programming 2022; 2: 22-36 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2022 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/497 |
| work_keys_str_mv |
AT sydorovmo mastersthesisinsoftwareengineeringobjectsubjectcontentsofresearch AT sydorovmo disertacíâmagístrívzínženerííprogramnogozabezpečennâobêktpredmetzmístdoslídženʹ |
| first_indexed |
2025-07-17T10:06:55Z |
| last_indexed |
2025-07-17T10:06:55Z |
| _version_ |
1850411256179064832 |
| fulltext |
22
Освітні та навчальні аспекти програмування
Вступ
Основи інженерії програмного за-
безпечення почали закладатися 1968 року
після першої конференції, що відбулася в
Гармиші (Німеччина) [1]. Вже на цій кон-
ференції було звернуто увагу на гостру
необхідність підготовки кадрів, неста-
ча яких була однією зі складових кризи
програмного забезпечення, що на той час
мала місце [2].
В Україні до 2006 року фахів-
ці з інженерії програмного забезпечен-
ня не готувалися. У рамках бакалаврату
комп’ютерні науки вивчали програмісти,
які після закінчення університету пере-
важно самостійно або на курсах набували
додаткові знання та вміння, щоб більш-
менш відповідати вимогам не тільки,
щодо кодувальника програм, а і щодо ін-
женера з програмного забезпечення. На
підприємствах тоді вже створеної Асоці-
ації «Інформаційні технології України»
(https://itukraine.org.ua/) відчувався го-
стрий брак справжніх фахівців, на рин-
ку праці їх було вкрай мало. Системного
розуміння причин ситуації не було. Вва-
жалося, що університети погано готують
фахівців. Тому великі компанії самі поча-
ли підготовку кадрів.
Слід зазначити, що в Україні, в
академічному середовищі ще раніше
були створені передумови для вирішен-
ня проблеми в контексті інженерії про-
грамного забезпечення. До цих переду-
мов слід віднести роботи, які велися в
Інституті кібернетики АН УРСР, здій-
снювалися дослідження і створювалися
програмні засоби для реалізації так зва-
ної технології програмування, під якою
розумілася саме інженерія програмного
забезпечення [3]. Глушков В.М. підтри-
мував ці роботи [4]. До Києва приїжджа-
ли відомі вчені, які працювали у цій га-
лузі, як радянські, так і закордонні. Зо-
крема, А. Єршов, Є. Дейкстра. 1978 року
проведено Першу Всесоюзну конферен-
цію з технології програмування [5]. 1995
УДК 502:004.45 (075.8) http://doi.org/10.15407/pp2022.02.022
М.О. Сидоров
ДИСЕРТАЦІЯ МАГІСТРІВ З ІНЖЕНЕРІЇ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ – ОБЬЄКТ,
ПРЕДМЕТ, ЗМІСТ ДОСЛІДЖЕНЬ
На відміну від закордонних університетів, в Україні протягом багатьох років склалася й існує прак-
тика формулювання мети дослідження, застосовуючи поняття об’єкта і предмета дослідження. І це,
як показав час, важливий етап роботи, від виконання якого залежить результативність дослідження.
Загальне й тотальне проникнення програмного забезпечення в життя з одного боку, а з іншого - поява,
спеціалізацій інженерії програмного забезпечення значно ускладняють умови виконання цього етапу
магістерського дисертаційного дослідження. Крім цього, в інженерії програмного забезпечення засто-
совуються наукові методи досліджень, які бажано мати на увазі і використовувати для виконання ма-
гістерського дисертаційного дослідження. Тому актуальними є питання щодо формулювання об’єкта
і предмета досліджень та застосування доказових методів їх виконання. За мету цієї статті ставилося
передовсім, надання рекомендації на основі фундаментальних положень інженерії програмного забез-
печення щодо формулювання об’єкта і предмета магістерської дисертації зі спеціалізації в контексті
інженерії програмного забезпечення. А також, вказати на застосування в магістерської дисертації на-
укових методів доказових досліджень і звернути увагу на оформлення результатів. Досягнення мети
статті розглядається в контексті причин і умов, які історично склалися в навчанні і відповідних про-
блем, які виникли в навчальних планах, виборі тем і змісті досліджень магістерських дисертацій. Одна
з причин, яка має об’єктивний характер, виникає в контексті сполучення домену інженерії програмно-
го забезпечення з прикладними доменами, яке є основою відповідної спеціалізації. Стаття розрахована
на магістрів зі спеціалізацій інженерії програмного забезпечення та їхніх наукових керівників.
Ключові слова: інженерія програмного забезпечення, навчання, магістерські дослідження, науково-
експериментальні методи досліджень.
© М.О. Сидоров, 2022
ISSN 1727-4907. Проблеми програмування. 2022. № 2
23
Освітні та навчальні аспекти програмування
року в Інституті кібернетики АН УРСР
була захищена перша в пострадянській
Україні докторська дисертація, присвя-
чена вирішенню актуальних на той час
завдань інженерії програмного забезпе-
чення, що належали до повторного вико-
ристання програмного забезпечення [6].
2000 року в Національному авіа-
ційному університеті було відкрито
першу в Україні кафедру інженерії про-
грамного забезпечення [7], а в Асоціації
«Інформаційні технології України», до
якої тоді належали тільки підприємства
індустрії програмного забезпечення
України, була введена позиція і обрано
віце-президента для зв’язку з універси-
тетами. Як виявилося пізніше, він мав
добре розуміння зв’язку проблем Асо-
ціації з відсутністю підготовки фахівців
саме з інженерії програмного забезпе-
чення. Тоді разом зі створеною кафе-
дрою і Асоціацією почалися роботи як
у викладацькому середовищі, так і в ін-
дустрії з роз’яснення необхідності під-
готовки кадрів з інженерії програмного
забезпечення. Таким чином було розпо-
чато підготовку до відкриття в Україні
бакалаврату з інженерії програмного за-
безпечення [8].
У контексті цих робіт у Націо-
нальному авіаційному університеті ка-
федрою інженерії програмного забез-
печення почав видаватися науковий
журнал «Інженерія програмного забез-
печення» [9], проводилася щорічна на-
уково-технічна конференція студентів
та аспірантів з однойменною назвою.
Також кафедрою інженерії програмного
забезпечення та Асоціацією «Інформа-
ційні технології України» було видано
публікації та проведено низку семінарів
і конференцій [10 - 12].
Навесні 2006 року бакалаврат
«Програмна інженерія» було відкрито, а
восени здійснено перший набір студен-
тів. До відкриття у Національному авіа-
ційному університеті було розроблено на-
вчальний план, на основі шаблону N2S-1c
з [13]. План було прийнято на конферен-
ції завідувачів кафедр, які готували бака-
лаврів та фахівців із комп’ютерних наук.
Ці кафедри, відповідно до рекомендації
міністерства освіти були зобов’язані пе-
реходити на підготовку бакалаврів з на-
пряму «Програмна інженерія» (інженерія
програмного забезпечення). Процедура
обговорення і прийняття цього плану ви-
світлила значні проблеми (що є і будуть в
майбутньому), які пов’язувалися з відсут-
ністю педагогічних кадрів, із розумінням,
як готувати саме інженерів з програмного
забезпечення.
Зараз більшість класичних та полі-
технічних університетів України готують
бакалаврів за спеціальністю 121 – «Інже-
нерія програмного забезпечення» та ма-
гістрів за відповідними спеціалізаціями.
В Україні створено освітні стандарти для
підготовки бакалаврів та магістрів [14].
На основі спеціальності 01.05.03 – «Ма-
тематичне та програмне забезпечення
обчислювальних машин, комплексів та
мереж» створено докторантуру філософії
спеціальності «Інженерія програмного
забезпечення».
Але проблеми 2006 року залиши-
лися і ненайкраще впливають на підго-
товку фахівців і саме магістрів.
Проблеми підготовки магістрів
з інженерії програмного
забезпечення
2006 року у Харкові на конферен-
ції з введення бакалаврату інженерії про-
грамного забезпечення в Україні, гру-
пою з Києва (Національний авіаційний
університет та Асоціація «Інформаційні
технології України») було запропоновано
навчальний план підготовки (Табл. 1, на-
ведено англійською мовою [13]).
Учасники конференції зустріли
план без ентузіазму. Пояснити це можна
трьома причинами:
1. Завідувачі кафедр розуміли, що
на кафедрах немає викладачів, спромож-
них викладати нові дисципліни за пла-
ном, і їх була переважна більшість;
2. У плані було показано різке ско-
рочення кредитів (навчальних годин)
у порівнянні із планами комп’ютерних
наук, на такі дисципліни як математика,
фізика, відсутня також низка дисциплін,
зокрема, з електротехніки, нарисної гео-
метрії тощо;
24
Освітні та навчальні аспекти програмування
Таблиця1.
Software engineering, Fundamental
and professional subjects
Name of subjects Credits
ECTS
2.1 Mathematical Analysis 3,00
2.2 Linear Algebra and Analytic
Geometry 3,00
2.3 Mathematical Statistics 3,00
2.4 Basics of Discrete Mathematics 5,00
2.5 Discrete Structures 3,50
2.6 Physics 4,00
2.7 Empirical Methods of Software
Engineering 4,00
2.8 Fundamental of Programming 7,00
2.9 Object Oriented Programming 7,00
2.10 Algorithm and Data Structures 5,00
2.11 Software Construction 4,00
2.12 Software Architecture and
Design
2.13 Computer Architecture 5,00
2.14 Software Requirements
Analysis 5,00
2.15 Social Safety and Labor
Protection 4,00
2.16 Software economic 1,50
2.17 Software Modeling 5,00
2.18 Computer Networks 3,00
2.19 Operating Systems 6,00
2.20 Group Dynamics and
Communications 2,00
2.21 Introduction to Software
Engineering 7,50
2.22 Database 6,00
2.23 Human Computer Interaction 3,50
2.24 Software Quality and Testing 4,00
2.25 Program and Data Security 3,50
2.26 Professional Software
Engineering Practice 2,50
2.27 Design Practice 1,50
2.28 Software Project Management 3,00
####
3. У плані також були відсутні дис-
ципліни, які традиційно викладалися в
комп’ютерних науках, як-от, чисельні
методи, основи прийняття рішень, дослі-
дження операцій, інформаційні техноло-
гії і т. і.
Проте групі з Києва вдалося знайти
підтримку деяких завідувачів кафедр, і
запропонований план було взято за осно-
ву. Пізніше цей план було рекомендовано
Навчально-методичною підкомісією до
застосування в стандарті при відкритті
бакалаврату «Програмна інженерія».
Але, позаяк, план мав рекоменда-
ційний характер, то і застосовували його
в повному обсязі тільки окремі універси-
тети, наприклад, Національний авіацій-
ний університет. На жаль, пізніше, коли
почали прийматися стандарти навчання
як першого, так і другого рівня в них
були відсутні навчальні плани. Їх опо-
середковано представляли переліки ком-
петенцій, вмінь та результатів навчання
і освітні програми. Реалізувати їх можна
було формально, шляхом створення будь-
якого плану, зручного кафедрі. І зараз,
зазвичай, ці плани найчастіше віддале-
но пов’язані з інженерією програмного
забезпечення. Пояснюється це тим, що
стан з відсутністю компетентних викла-
дачів, на жаль, не змінився.
Наразі залишаються умови, через
які виникли проблеми і з підготовкою
магістрів. Проблеми виявилися знову,
ще і в навчальних планах і виборі тем,
і в змісті досліджень магістерських дис-
ертацій. Ситуація, що склалася, має три
причини. Дві є наступними (про третю
трохи згодом):
1. Підготовка бакалаврів тільки
частково відповідає спеціальності;
2. Некомпетентність в інженерії
програмного забезпечення викладачів–
наукових керівників магістрів.
Як бачимо, обидві причини сяга-
ють корінням у минуле. Наслідком пер-
шої причини є неготовність студентів до
грамотного розв’язання завдань інжене-
рії програмного забезпечення. Наслідком
другої причини є вибір тем магістерських
досліджень, далеких від інженерії про-
грамного забезпечення. Ці ж причини
«працюють» у бакалаврських дипломних
роботах. Наприклад, типові теми для ба-
калаврських робіт - це будь який Web-
сайт, зокрема, засоби моніторингу про-
дажу квитків, контролю артеріального
тиску, серцево-судинної системи, розта-
шування сервісів у місті тощо.
Розглядаючи навчання магістрів,
звернемо увагу на питання вибору
об’єкта та предмета дослідження, а також
25
Освітні та навчальні аспекти програмування
на структуру та зміст дисертації. Споді-
ваємося, що відповіді на ці питання, які
пропонуються в статті, допоможуть на-
уковим керівникам і студентам відповід-
них спеціалізацій Інженерії програмного
забезпечення.
Аналіз літератури
Усі праці, близькі за темою цій
статті, можливо поділити на три групи.
До першої групи віднесемо пра-
ці, які стосуються становлення навчання
інженерії програмного забезпечення як
окремої спеціальності [14 - 19]. До дру-
гої групи - праці, які стосуються змісту
навчання, саме інженерії програмного за-
безпечення як, скажімо, окремого напря-
му підготовки (бакалаврату) [20 - 27]. До
третьої групи віднесемо праці, що стосу-
ються підготовки магістрів [28 - 34]. Зро-
зуміло, що найбільш близькими до теми
цієї статті є праці третьої групи.
Зміст праць першої групи найчас-
тіше зосереджувався на ознаках інженерії
програмного забезпечення як інженерної
діяльності [17-19]. Ознаки зазвичай по-
казувалися на прикладі відмінності ін-
женерії програмного забезпечення від
комп’ютерних наук [15]. Це пов’язано
с відокремленням свого часу, інжене-
рії програмного забезпечення як освіт-
ньої і виробничої спеціальності саме від
комп’ютерних наук.
Визначається, що, по-перше,
ці дві галузі діяльності відрізняють-
ся за методом творчого мислення. Для
розв’язання завдань комп’ютерних наук
застосовується метод конвергентного
мислення, коли для розв’язання перед-
бачаються точні (часто математичні) ін-
струкції, тож мається на увазі, що існує
єдине рішення. Це вказує на те, що за-
дачі комп’ютерних наук мають переваж-
но теоретичне підґрунтя. Для вирішення
завдань інженерії програмного забезпе-
чення застосовується метод дивергент-
ного мислення, коли для розв’язання
пропонується декілька рішень. Серед рі-
шень обирається одне й до його реаліза-
ції застосовується метод конвергентно-
го мислення. Водночас на вибір єдиного
рішення впливають чимало факторів,
більшість з яких пов’язані а практичним
підґрунтям розв′язуваного завдання.
По-друге, результат розв’язання
завдання інженерії програмного забезпе-
чення завжди є продуктом, у якого є ко-
ристувач. Продукт створюється в контек-
сті життєвого циклу і має задовільняти
низку вимог, характерних для інженерії
(конструкція продукту, якість, стандар-
ти, документованість, супровід, вплив
на зовнішнє середовище). Одночасно,
частина робіт першої групи присвячена
з’ясуванню поняття «інженер із програм-
ного забезпечення» [17, 18].
Праці другої групи насамперед
було присвячено з’ясуванню навчання як
переходу від окремої або декількох дис-
циплін до системно сформованого пере-
ліку дисциплін, спрямованого на навчан-
ня спеціальності за відповідним змістом.
Дискусії навколо змісту навчання засно-
вані на обговоренні або використанні
SWEBOK [21]. Для побудови навчальних
планів і програм переважна більшість
університетів почала застосовувати реко-
мендації SE2004 [14].
На сьогодні інженерія програмного
забезпечення - це систематизований, ре-
гламентований і квантифікований підхід
до реалізації процесів створення, експлу-
атації, супроводу та утилізації програм-
ного забезпечення. До того ж процеси,
ресурси та програмні продукти інженерії
програмного забезпечення мають відпо-
відати заданим технічним, економічним,
соціальним, правовим вимогам, а також
вимогам стійкого розвитку, зокрема, «зе-
леним» [35 ].
Праці третьої групи спрямовані
на підготовку з інженерії програмного
забезпечення з урахуванням існуючих
практик - прикладних доменів [28-33].
Хоча дослідження в інженерії програм-
ного забезпечення, безумовно, також
потребують підготовки магістрів, саме
наявність прикладних доменів врахову-
ється в підготовці магістрів переважною
кількістю університетів, і вона приво-
дить до появи відповідних спеціалізацій
спеціальності Інженерія програмного
забезпечення. Водночас існують роботи,
де ці практики класифіковані, зокрема,
26
Освітні та навчальні аспекти програмування
шляхом аналізу понад десяти тисяч ви-
конаних проєктів [31]. Подібні класифі-
кації забезпечують аргументовану базу
для вибору спеціалізацій щодо підго-
товки магістрів. Але, як показує аналіз
і досвід автора, наявність прикладних
доменів часто призводить до абсолют-
ного зсуву акцентів досліджень магіс-
терських дисертацій з об’єктів і предме-
тів інженерії програмного забезпечення
в прикладні домени. Тому зауважимо,
що саме зсув змісту навчання магістрів
і, зокрема, досліджень магістерських
дисертацій з інженерії програмного за-
безпечення на окремі прикладні домени
є третьою причиною появи питань, які
розглядаються в статті. Таким чином, до
проблем підготовки студентів і некомпе-
тентності викладачів додається пробле-
ма сполучення домену інженерії про-
грамного забезпечення з прикладними
доменами, наприклад [29], військовим
– застосунки для військових; з домена-
ми систем – застосунки для управління
пристроями; комерційним – застосунки
для обробки інформації різноманітного
представлення (текстового, графічного,
табличного, планування ресурсів тощо);
аутсорсинговим доменам – застосунки,
які виконуються, мають відмінності в
зв’язку з контрактними відношеннями;
інформаційних систем – застосунки для
управління бізнес функціями.
Разом с тим, огляд літератури по-
казує, що в умовах, які склались, відсут-
ні роботи щодо особливостей підготов-
ки магістерських дисертацій з інженерії
програмного забезпечення в умовах, які
склалися. Водночас, якщо перши дві при-
чини проблем підготовки магістрів мож-
на і потрібно усувати, то третя причина
- об’єктивна і її треба враховувати під час
навчання магістрів.
Це стосується визначення об’єкта
й предмета дисертації, назви, змісту та
опису досліджень і результатів з ураху-
ванням наявності прикладного домену.
На відміну від закордонних університе-
тів, в Україні протягом багатьох років
склалася й існує практика формулювання
цілей дослідження, застосовуючи понят-
тя об’єкта і предмета дослідження. І це,
як показав час, важливий етап, від вико-
нання якого залежить результативність
дослідження.
Магістерська дисертація.
Об’єкт та предмет
Основи наукових досліджень вчать,
що, перш ніж братися безпосередньо за
виконання досліджень необхідно визна-
чити об’єкт і предмет дослідження.
Об’єкт дослідження визначається
шляхом встановлення найбільш загаль-
ного явища в домені, в контексті якого
буде виконуватися дослідження. Це да-
ність, яка легко встановлюється, якщо у
дослідника достатньо знань про сутність
дослідження і досліджуваного домену.
Для спеціалізацій, що розглядаються, це
знання з домену - Інженерія програмного
забезпечення.
Предмет дослідження належить
до одного або декількох аспектів явища,
яке визначено в якості об’єкта досліджен-
ня і визначається метою дослідження, на
основі особливостей прикладного доме-
ну. Для спеціалізацій, що розглядаються,
цей домен може бути, зокрема, наступ-
ним - Інформаційні системи і обробка да-
них (SAS.inf Information systems and data
processing [13]).
Правильність вибору об’єкта і
предмета дослідження впливає з одного
боку на результативність дослідження, а з
іншого - на можливість правильної оцін-
ки отриманих результатів.
Якщо об’єкт і(або) предмет дослі-
дження обрано невірно, тоді мають місце
два випадки.
У першому випадку виявляється,
що отримані результати аж ніяк не є тими,
що мають бути отримані в досліджувано-
му домені.
У другому випадку, експерти (ек-
заменаційна комісія), увага яких спрямо-
вуватиметься на оцінку результатів дослі-
дження, можуть виявитися не спеціаліс-
тами в домені, в якому, за припущенням
дослідника, проводилося дослідження.
Як наслідок - оцінити результати експер-
ти не зможуть.
Зв’язок об’єкта і предмета му-
ситьбути безпосереднім і вимагати, аби
27
Освітні та навчальні аспекти програмування
об’єкт і предмет були на перетині доме-
нів спеціалізації, а саме, як-от Інженерія
програмного забезпечення й Інформацій-
ні системи і обробка даних. Запропонує-
мо рекомендації щодо визначення цього
зв’язку.
Для визначення зв’язку між
об’єктом і предметом необхідна інфор-
мація для уточнення поняття об’єкта до-
слідження. Будемо це робити, використо-
вуючи поняття життєвого циклу як систе-
моутворюючого в інженерії програмного
забезпечення (Рис.1).
Одночасно, використовуємо те, що
всі фази життєвого циклу мають три скла-
дові - продукт, процес і ресурс (Рис. 2).
Таким чином, конкретизуючи мож-
ливий об’єкт дослідження, будемо розгля-
дати наступне (рис.3): продукти (робочі
продукти - результати виконання проце-
сів фаз життєвого циклу; програмні про-
дукти - результати виконання життєвого
циклу при створенні програмного забез-
печення); процеси (процеси фаз життєво-
го циклу); ресурси, розділяючи їх на дві
частини, ресурси І - програмно-реалізо-
вані ресурси (інструменти і артефакти,
наприклад, тести, представлення стилів,
документи) і ресурси ІІ. До ресурсів ІІ
віднесемо підходи і методи, використо-
вувані в інженерії програмного забезпе-
чення. Наприклад, підхід компонентного
створення і супроводження, метод Scram,
щодо організації команд (організацій ) за
методологію Agile. В процесі конкрети-
зації обов’язково маємо на увазі наступні
розділи інженерії програмного забезпе-
чення: різновид інженерії – пряма, зво-
ротна, емпірична (метричне забезпечен-
ня); горизонтальні процеси і відповідні
продукти - документування, валідація,
верифікування, керування, гарантування
якості; економіка програмного забезпе-
чення; зелене програмне забезпечення і
сталий розвиток; культура інженерії про-
грамного забезпечення і правові питання;
екосистеми програмного забезпечення.
Наведені уточнення об’єкта дослі-
дження слід розглядати в контексті чоти-
рьох під доменів спеціалізації інженерії
програмного забезпечення:
- прикладному, для якого створю-
ється програмне забезпечення (програм-
ний продукт). Наприклад, згідно з спе-
ціалізацією, це інформаційні технології
(представлена відповідними знаннями
XBoK, як-от, для інформаційних систем і
технологій це CBoK [36]);
- проблемному, в якому розв’я-
зуються нові, чи удосконалюються рі-
Рисунок 1. Життєвий цикл
Рисунок 2. Складові фаз життєвого циклу
28
Освітні та навчальні аспекти програмування
шення існуючих, наукові завдання щодо
створення і супроводження програмно-
го забезпечення (програмний продукт)
- наукова частина домену інженерії про-
грамного забезпечення (представлена
SWEBoK [21]);
- реалізаційному, в якому створю-
ється програмне забезпечення (програм-
ний продукт) – інженерна частина доме-
ну інженерії програмного забезпечення
(представлена SWEBoK);
- домену оцінювання і впроваджен-
ня результатів, де перевіряються окремі
властивості отриманих результатів та до-
сліджуються питання їх впровадження –
практична частина домену інженерії про-
грамного забезпечення.
Зв’язки цих доменів визначають
структуру магістерського дослідження
(рис. 4).
Таким чином, для формулюван-
ня об’єкта, предмета та назви дисертації
необхідно виконати наступні три кроки
(рис. 5):
Аналізуючи завдання дослідження,
яке сформульовано в прикладному доме-
ні, обираємо в домені інженерії програм-
ного забезпечення об’єкт дослідження,
Рисунок 3. Об’єкт дослідження. Класифікація
Обьект
дослідження
Програмне
забезпечення
Продукти
Робочі
продукти
Програмні
продукти
Фази життевого
циклу
Процеси Ресурси І,ІІ
Програмні
інструменти
Артефакти Методи Команди
(організації)
Рисунок 4. Структура магістерського дослідження
SWEBoK XBoK
Проблемний домен
З'ясування і
розв'язання завдання
Прикладний домен
Завдання
Технічне розв'язання
завдання (реалізація)
Перевірка і
оцінювання
Вп
ро
ва
дж
ен
ня
Реалізаційний домен Оцінювання і впровадження домен
До
сл
ідж
ен
ня
лі
те
ра
ту
ри
(S
yst
em
ati
c M
ap
pin
g S
tud
y),
Ак
ти
вн
е
до
сл
ідж
ен
ня
(A
cti
ve
, D
es
ign
sc
ien
ce
) R
es
ea
rch
,
Пе
ре
вір
ка
рі
ше
нь
, я
кі
пр
ий
ня
то
(C
as
e S
tu
dy
)
29
Освітні та навчальні аспекти програмування
спираючись на класифікацію, наведену
на рис. 1-3.
Продовжуючи аналіз завдання,
уточнюємо (якщо потрібно, шляхом ви-
конання розвідувального дослідження
літератури, рис. 6) об’єкт дослідження та
встановлюємо предмет дослідження, який
визначається об’єктом та цілями (завдан-
ням) дослідження. Як правило, це мето-
дології, методи, моделі і засоби створен-
ня і супроводу програмного забезпечення
або відповідне уточнення (продукти, про-
цеси, ресурси) згідно із наведеними ри-
сунками 1-3 для прикладного домену.
Нарешті формулюємо назву дисер-
тації. Здебільшого назва дисертації спів-
падає з формулою предмета дослідження.
Після виконання цих кроків можна
починати магістерське дослідження згід-
но із структурою, яку наведено на рис. 4.
Застосування рекомендацій
Розглянемо такий випадок. Спеці-
алізація - інженерія програмного забез-
Рисунок 5. Зв’язок завдання-об’єкт-предмет-назва дисертації
Обираємо об'єкт (маючи
на увазі, рис.1-3)
Уточнюємо об'єкт та
встановлюємо предмет
(враховуючи завдання)
Завдання
дослідженняФормулюємо
назву
дисертації
))
1
2222
ц
3
Інформаційні
системи і
технології
Інженерія
програмного
забезпечення
Рисунок 6. Уточнення об’єкта та встановлення предмета
Завдання Назва
Об'єкт Предмет
Розвідувано
дослідження літератури
30
Освітні та навчальні аспекти програмування
печення інформаційних систем і техно-
логій, домен - інженерія програмного за-
безпечення, прикладний домен – інфор-
маційні системи і технології. Завдання
– створити і дослідити Web - сервіс, що
забезпечує прийняття рішень на основі
неповної інформації.
Досвід показує, що зазвичай за
об’єкт дослідження обирають програмне
забезпечення Web – сервісу.
В цьому випадку предметом до-
слідження визначають метод і алгорит-
ми прийняття рішень на основі неповної
інформації (незалежно від того, існують
вони чи ні), які необхідно встановити і
реалізувати в рамках програмного забез-
печення Web - сервісу.
Отож, якщо об’єкт дослідження ви-
значено майже відповідно до домену, то
предмет не має ніякого відношення, ні до
інженерії програмного забезпечення, ні до
перетину цього домену і прикладного до-
мену. Метод і алгоритми прийняття рішень
на основі неповної інформації як предмет
дослідження цілком належить до домену
інформаційних систем і технологій.
Таким чином, отримані результати
(метод і алгоритми прийняття рішень на
основі неповної інформації) будуть тіль-
ки частково належати до спеціалізації,
тому експерти з цієї спеціалізації не змо-
жуть їх визначити. Потрібні також екс-
перти з іншого домену, а саме з домену
інформаційних систем і технологій. Хоча
дослідник повністю переконаний у пра-
вильності визначення об’єктом програм-
не забезпечення, предмет дослідження
може бути з ним і не пов’язаний.
Скористаємося вище згаданими
кроками (рис.5, 6). На виконання кроку
1 об’єктом дослідження для наведеного
випадку (беручи до уваги, що Web – сер-
віс реалізується шляхом створення від-
повідного програмного забезпечення, а
інших уточнень у завданні немає) може
залишатися програмне забезпечення Web
- сервісу, що уможливлює прийняття рі-
шень на основі неповної інформації, або
відповідне уточнення згідно з наведени-
ми рисунками 1-3.
На другому кроці (рис. 5) цілями
(завданням) дослідження визначається
предмет дослідження. Як правило, це ме-
тодології, методи, моделі й засоби ство-
рення й супроводу програмного забезпе-
чення, або відповідне уточнення (якщо
є в завданні). А саме продукти, процеси,
ресурси відповідно до наведених рисун-
ків 1-3. Наприклад, якщо програмне за-
безпечення розглядається в контексті
прийняття рішень на основі неповної ін-
формації, предметом може бути наступне:
компоненти неодноразового використан-
ня (необов’язково програмні) відповідної
форми (робочий продукт фази доменного
аналізу) для створення програмного за-
безпечення Web - сервісу, або процес(и)
(фаза(и) життєвого циклу) створення і
супроводження програмного забезпечен-
ня. Або ж представлення і перетворен-
ня знань для створення і супроводження
програмного забезпечення (ресурс І – ар-
тефакт) або підхід (метод) для створення
і супроводження програмного забезпе-
чення (ресурс ІІ) .
В такому разі перевизначимо пред-
мет дослідження наведеного раніше при-
кладу наступним чином, - методи (і, мож-
ливо, засіб), моделі, інструменти ство-
рення (супроводження) програмного за-
безпечення Web - сервісу, що забезпечує
реалізацію методу прийняття рішень на
основі неповної інформації.
Можливі й інші визначення пред-
мету дослідження залежно від уточнень,
які можуть бути в завданні:
- методи, моделі, інструменти ство-
рення і супроводження компонентів нео-
дноразового використання для Web - сер-
вісу, що забезпечує прийняття рішень на
основі неповної інформації;
- методи, моделі, інструменти для
реалізації процесу(ів) створення і супро-
водження програмного забезпечення Web
- сервісу, що уможливлює прийняття рі-
шень на основі неповної інформації;
- методи, моделі, інструменти для
представлення і перетворення знань щодо
програмного забезпечення Web - сервісу,
яке гарантує прийняття рішень на основі
неповної інформації.
Відповідно, предметом досліджен-
ня буде не метод і алгоритми прийняття
рішень на основі неповної інформації, як
31
Освітні та навчальні аспекти програмування
це визначено раніше, а метод створення
(далі за об’єктами наведених прикладів)
програмного забезпечення Web - сервісу,
в якому застосовуються метод і алгорит-
ми прийняття рішень на основі неповної
інформації.
Як бачимо, об’єкт дослідження
- це програмне забезпечення, а, визна-
чаючи предмет, уточнюємо - робочий
продукт, процес, або артефакт для при-
кладного домену - інформаційні систе-
ми і технології, де передбачається ви-
користання певних методів і алгоритмів
прийняття рішень. Водночас викорис-
тання методу і алгоритмів потребує на-
ступного: розробки нового, або суттєво-
го удосконалення існуючого підходу до
створення або супроводження програм-
ного забезпечення; створення і супро-
водження компонентів неодноразового
використання; реалізації процесу(ів)
створення і супроводження програмного
забезпечення; створення інструментів
для представлення і перетворення знань
щодо програмного забезпечення.
Звісно, використання методу і ал-
горитмів прийняття рішень у рамках про-
грамного забезпечення Web - сервісу має
вимагати розв’язання певного науково-
практичного завдання, що обов’язково
належить до інтересів інженерії програм-
ного забезпечення. Для розв’язання цьо-
го завдання в процесі дослідження і буде
створюватися метод та, ймовірно, засіб.
Саме ці метод і засіб мають бути резуль-
татами дисертаційного дослідження, а не
програмне забезпечення Web - сервісу,
що забезпечує прийняття рішень на осно-
ві неповної інформації.
Виконуючи крок 3, беремо до ува-
ги, що визначення предмету дослідження
практично завжди буде назвою дисертації.
Так, зокрема, маємо наступні назви:
Метод і засіб створення і супро-
водження компонентів неодноразового
використання щодо розробки і супрово-
дження програмного забезпечення Web
- сервісу, який забезпечує прийняття рі-
шень на основі неповної інформації.
Метод і моделі щодо реалізації
процесу специфікування вимог програм-
ного забезпечення Web - сервісу, який за-
безпечує прийняття рішень на основі не-
повної інформації.
Моделі і інструменти для пред-
ставлення і перетворення знань щодо
створення і супроводження програмного
забезпечення Web - сервісу, яке уможлив-
лює прийняття рішень на основі неповної
інформації.
Магістерська дисертація. Зміст
Після визначення об’єкта і пред-
мета дослідження можна виконувати до-
слідження. Магістерська дисертація як
основне дослідження (звичайно, це action
research [15]) має наступні складові:
- розвідувальне дослідження для
з’ясування об’єкта та предмета осно-
вного дослідження. Як правило, його
не буває, якщо досвіду наукового ке-
рівника і знань студента достатньо.
Але через умови, про які йшла мова
раніше, це дослідження необхідно
проводити;
- вивчення стану об’єкта (предмета),
шляхом дослідження літератури. Міс-
титься в першому розділі дисертації;
- основне (первинне) дослідження
(action research) – дослідження пред-
мета і створення теорії, підходу, ме-
тоду, засобу, моделі або іншого для
вирішення практичної задачі (відпо-
відно назви дисертації). Міститься в
другому та третьому розділах дисер-
тації;
- дослідження теорії, підходу, методу,
засобу, моделі або іншого, які створе-
но в основному дослідженні (вторин-
не дослідження). В деяких випадках
може сполучатися з контрольованим
експериментом. Міститься в четвер-
тому розділі дисертації.
Отож, зазвичай, текст магістер-
ської дисертації описує результати трьох
досліджень і містить чотири розділи.
З’ясування та вивчення стану
об’єкта і предмета здійснюються шля-
хом дослідження літератури. Для вико-
нання цих досліджень в інженерії про-
грамного забезпечення найчастіше за-
стосовують метод Систематичного огля-
ду літератури - Systematic mapping study
[37]. Це метод вторинного дослідження,
32
Освітні та навчальні аспекти програмування
яке використовує чітко визначену мето-
дологію для виявлення, аналізу та інтер-
претації всіх наявних доказів, пов’язаних
із конкретним, первинним дослідженням,
тож, є неупередженим та (певною мірою)
повторюваним, а тому доказовим.
Основними етапами процесу до-
слідження за методом Systematic mapping
study є визначення дослідницьких питань,
проведення пошуку відповідних джерел,
відбір джерел, дослідження анотацій та
безпосередньо текстів, котрі знайдено
за ключовими словами, збір і представ-
лення даних [37]. Кожен етап процесу
має результат. Кінцевим є графічне пред-
ставлення результатів дослідження та об-
говорення. Основною метою Systematic
mapping study є огляд літератури щодо
досліджуваної галузі, визначення кіль-
кості та типу досліджень, а також наяв-
них у галузі результатів. Крім цього, іс-
нує ще дві цілі досліджень:
- перша - відображення частоти публі-
кацій і їх хронології, щоб побачити
тенденції досліджень;
- друга - визначення джерел, на які спи-
ралися дослідження в цій галузі.
Для візуалізації результатів зазви-
чай застосовують діаграму бульбашок з
MS Excel.
У частині розділу – обговорення
стану досліджень предмету дисертації
з повним та інтенсивним застосуванням
посилань на знайдені джерела. Після чого
формуються підстави для проведення
первинного (основного) дослідження.
Первинне дослідження (action
research) – дослідження предмета і ство-
рення теорії, підходу, методу, засобу, моде-
лі тощо для вирішення науково-практичної
задачі, яку поставлено в дисертації.
Активне (дієве) дослідження
(Action research) – це дослідження, з ме-
тою розв’язання науково-практичної за-
дачі науковими методами, шляхом впливу
на явище з будь-якого аспекту або зміною
явища, що є фокусом дослідження [38].
Рішення задачі здебільшого потребує
вивчення відповідного явища в аспекті
предмета дослідження. Тож, активне (ді-
єве) дослідження поєднує наукові методи
з практичними задачами, які потребують
розв’язання. Водночас дослідник пови-
нен втручатися (впливати, діяти) в явище,
змінюючи і перетворюючи його або його
контекст. Активне дослідження має гли-
бокий гносеологічній характер, тому, на
жаль відсутні методики його проведення.
Тут важливу роль відіграє науковий керів-
ник здобувача. Саме від нього залежить,
чи буде досягнута мета, чи будуть відпо-
відати результати активного дослідження
темі дисертації. Відповідність буде пере-
вірено шляхом виконання вторинного до-
слідження.
Вторинне дослідження, метод до-
слідження результату (action research
- Case Study). Case study - це метод ви-
конання наукових досліджень, зокрема,
в інженерії програмного забезпечення,
невеликих явищ. Здебільшого застосо-
вується для обґрунтування результатів
первинного дослідження наукових ста-
тей, бакалаврських робіт, магістерських
дисертацій. Тому засвоєння цього методу
і застосування в магістерської дисерта-
ції додає дисертації наукового, ґрунтов-
ного і доказового характеру. Case Study
- це метод досліджень результату Action
research, для розуміння та пояснення яви-
ща чи перевірки теорії, методу або засобу,
отриманих у результаті виконання осно-
вного дослідження, використовуючи пе-
реважно (але необов’язково) якісний ана-
ліз [39]. Case Study - це емпіричний метод
дослідження. Це не підмножина, або варі-
ант інших методів, таких як, контрольо-
ваний експеримент, огляд чи історичне
дослідження [40]. Case Study спрямоване
щодо об’єкта та предмета основного до-
слідження на наступне:
1. Детально відповідає на питання
«як і навіщо»;
2. Забезпечує глибоке розуміння
причин і наслідків основного дослідження;
3. Забезпечує тестування теорій і
методів, засобів, запропонованих у пер-
винному дослідженні, коли змінні недо-
статньо керовані.
Існують наступні типи Case Study [39]:
- пояснювальний – досліджує і по-
яснює «як і чому так?». Наприклад, по-
казує різницю між теоріями, підходами,
методами або сутність теорії, підходу, ме-
33
Освітні та навчальні аспекти програмування
тоду, або переваги теорії, підходу, методу,
які створено;
- описовий – досліджує і показує
«як це діє?» - можна віднести до засобів,
які створено;
- причинний – досліджує і показує
«яким чином?». Наприклад, як створений
стиль кодування впливає на розуміння
вихідного коду. Цей тип можна визначати
шляхом оцінювання ефективності отри-
маних результатів;
- розвідувальний (попередній) –
досліджує і показує «який стан?». На-
приклад, дослідження літератури для
з’ясування стану дослідження об’єкта або
предмета основного дослідження, зокре-
ма, за методом Systematic mapping study.
Може бути Case study змішаного
типу. Case study є добре регламентова-
ним методом. Існують докладні методики
щодо виконання того чи іншого типу Case
study [39].
Case study також має об’єкт та
предмет, які формулюють у контексті
результатів основного дослідження. На-
приклад, основне дослідження – Метод і
засоби редокументування успадкованого
програмного забезпечення; Основне до-
слідження – об’єкт - успадковане про-
грамне забезпечення; предмет – процеси,
моделі, методи, засоби редокументуван-
ня успадкованого програмного забезпе-
чення. Тоді Case study - об’єкт - процеси,
моделі, методи, засоби редокументуван-
ня успадкованого програмного забезпе-
чення; предмет – метод і засіб редоку-
ментування успадкованого програмного
забезпечення, розроблені в основному
дослідженні. Питання Case study – Чи
працездатні та ефективні метод і засіб
редокументування успадкованого про-
грамного забезпечення, створені в осно-
вному дослідженні?
У виконанні досліджень щодо ін-
женерії програмного забезпечення дуже
важливо застосування вимірювань [40].
Для цього існують метрики і відповідні
вимірювачі. Але трапляються випадки,
найчастіше саме у проведенні основних
досліджень і Case study, коли потрібних
метрик або не існує або не зрозуміло які
метрики слід застосовувати в конкретно-
му випадку. Тоді використовують широко
відомий в інженерії програмного забез-
печення метод ціль-питання-метрика -
GQM [41].
Метод GQM базується на припу-
щенні, що для цілеспрямованого вимірю-
вання, спочатку необхідно вказати ціль, а
далі простежити цю ціль до метрик, які
призначені для кількісного визначення
цілі і, зрештою, забезпечити основу для
інтерпретації метрик щодо заявленої цілі.
Для полегшення простеження цілі до ме-
трик застосовують питання, які поясню-
ють ціль. Таким чином модель GQM має
три рівні: концептуальний (ціль); опера-
ційний (питання); кількісний (метрики).
Концептуальний рівень (Goal) ви-
значає мету для об’єкта вимірювань з різ-
них причин і точок зору, щодо конкрет-
ного середовища. Об’єкти вимірювання
такі: продукти, процеси, ресурси.
Операційний рівень (Question) ви-
значає набір питань, які використовують-
ся для характеристики способу оцінки/
досягнення конкретної мети. Формулю-
вання питань має здійснюватися на осно-
ві характеристик об’єкта. Питаннями на-
магаються охарактеризувати об’єкт вимі-
рювання (продукт, процес, ресурс) і ви-
значити його з обраної точки зору.
Кількісний рівень (Metric) - це на-
бір даних, метрика. Пов’язаний з кожним
запитанням для відповіді на них кількіс-
но. Дані можуть бути наступними:
- об’єктивні - якщо вони залежать
лише від об’єкта, властивість якого вимі-
рюється, а не від точки зору. Наприклад,
кількість версій документа, кількість го-
дин, витрачених на виконання завдання,
розмір програми.
- суб’єктивні - якщо вони залежать
і від об’єкта, властивість якого вимірю-
ється, і від точки зору. Скажімо, чита-
бельність тексту, рівень задоволеності
користувачів.
Наприклад, об’єкт – стандарт ко-
дування (ресурс), призначення – підви-
щення ефективності кодування, фокус –
програмування, точка зору – менеджера,
середовище – мова програмування.
Оформлення результатів (Good
papers). Результати досліджень пред-
34
Освітні та навчальні аспекти програмування
ставляються відповідними дослідниць-
кими текстами. Найпоширенішими фор-
мами є стаття та дисертація. В інженерії
програмного забезпечення дослідницькі
тексти є звичними засобами для доне-
сення науковій спільноті результатів до-
слідження [42]. У дослідницькому тексті
автор пояснює зацікавленим читачам, як і
яких результатів він досягнув, чому чита-
чу слід читати цей текст. Якісний дослід-
ницький документ має відповісти на ряд
питань [42]:
- Яким саме є ваш результат?
- На яке запитання ви відповіли
(предмет дослідження) ?
- Чому для читача важливий ваш
результат?
- У контексті якого ще більшого пи-
тання поставлено питання, на яке ви від-
повіли (об’єкт дослідження)?
Щодо отриманого результату слід
дати відповіді на наступні запитання:
- Які нові знання вашого результа-
ту читач може використати?
- Яку попередню роботу (вашу чи
чужу) ви намагаєтесь вдосконалити?
- Чим ваш результат відрізняється і
є кращим за цю попередню роботу?
- Яким конкретно є ваш новий ре-
зультат?
- Чому читач має вірити вашому ре-
зультату?
- Який стандарт (методику) слід
використовувати для оцінки вашого ре-
зультату?
-Які конкретні докази свідчать, що
ваш результат задовольняє вашу вимогу?
Якщо автор чітко відповідає на
ці запитання, він, імовірно, добре усві-
домлює і може донести до читача свій
результат. Якщо до того ж результат ці-
кавий, зрілий та вагомий для приклад-
ного домена в контексті інженерії про-
грамного забезпечення, то це хороший
шанс для позитивної ухвали на захисті
дисертації.
Висновки
Метою цієї статті було узагальнен-
ня базових положень щодо формулюван-
ня об’єкта і предмета магістерської дис-
ертації зі спеціалізації інженерії програм-
ного забезпечення в умовах які склалися
в Україні. По-друге, надання рекоменда-
цій щодо застосування в магістерській
дисертації наукових методів досліджень і
оформлення результатів.
На відміну від закордонних уні-
верситетів, в Україні протягом багатьох
років склалася практика формулювання
цілей дослідження, застосовуючи понят-
тя об’єкта і предмета дослідження. І це,
як показав час, важливий етап, від вико-
нання якого залежить результативність
дослідження. Загальне й тотальне про-
никнення програмного забезпечення в
життя, з одного боку, і поява спеціаліза-
цій інженерії програмного забезпечення -
з іншого, значно ускладнюють виконання
цього етапу дисертаційного досліджен-
ня. Тому актуальними є питання щодо
формулювання об’єкта і предмета дослі-
джень та застосування доказових методів
їх виконання.
Отож, розглянуті умови, в яких за
яких в Украйні здійснюється навчання
магістрів, наведено рекомендації щодо
формулювання об’єкта та предмета дис-
ертаційного дослідження на основі фун-
даментальних положень інженерії про-
грамного забезпечення, розглянуто мето-
ди доказових досліджень.
Література
1. Report on a conference sponsored by the NATO
science committee, Garmisch, Germany, 7th to
11th October 1968, Editors: Peter Naur and
Brian Randell.
2. Boehm B., 2006, A View of 20th and 21st
Century Software engineering [Text].
ICSE’06. May 20–28. China. 2006. P. 12–29.
3. Вельбицкий И.В. Технология программи-
рования. [Текст]. Техника. Киев. Украина.
1984. 279 с.
4. Глушков В.М., Вельбицкий И.В. Техно-
логия программирования и проблемы ее
автоматизации. [Текст]. УСИМ. Kиев. №
6. 1976. С. 75–93.
5. Технология программирования: Тез. докл.
1-й Всесоюз. конф., Киев, октябрь 1978
г. Пленарные докл. И общ. материалы. –
Киев: Ин-т кибернетики АН УССР, 1979.
6. Сидоров М.О. Інженерія утилізації про-
грамного забезпечення систем управлін-
35
Освітні та навчальні аспекти програмування
ня та ЕОМ.- Автор. Дис.на здобуття наук.
ступ. докт. техн. наук..- Інститут кіберне-
тики імені В.М.Глушкова НАН України.-
1995 р. 25 с.
7. Сидоров М.О. Кафедра інженерії про-
грамного забезпечення. Компьютер-Клас!
2001. № 8. С. 17–19.
8. Бондаренко М., Сидоров М., Морозова Т.,
Мендзебровський І. Модель випускни-
ка бакалаврату «Програмна інженерія»,
Вища школа. 2009. № 4. C. 50–61.
9. https://nau.edu.ua/ua/menu/science/faxovi-
vidannya/
10. Сидоров Н.А. Инженерия программного
обеспечения – дисциплина или бакалаврат?
Матеріали міжнародної науково-
практичної конференції «Розробка систем
програмного забезпечення: виклики часу
та роль інформаційному суспільстві».
Київ, 27-28 січня 2005 р.
11. Сидоров Н.А. Инженерия ПО -дисциплина
или бакалаврат? Корпоративные системы.
№ 2. 2005. С. 22–27.
12. Сидоров Н.А. Инженерия программного
обеспечения – учебная дисциплина или
подготовка бакалавра? Управляющие си-
стемы и машины. 2006. № 2. С. 25–34.
13. Software Engineering 2004 Curriculum Guide-
lines for Undergraduate Degree Programs in
Software Engineering A Volume of the Com-
puting Curricula Series, August 23, 2004
14. Накази Міністерства освіти і науки
України від 29.10.2018 № 1166, 17.11.2020
р. № 1424
15. Parnas D. Software Engineering Programmes
are not Computer Science Programmes//
Annals of Software Engineering.- April 9,
1998, P1-16.
16. Boehm B. k “The IEEE-ACM Initiative
on Software Engineering as a Profession”,
IEEE Computer Society Software Engineer-
ing Technical Council Newsletter, Vol. 13,
No. 1, Sept. 1994, page 1.
17. Cheston, G.A. and Tremblay, J., Integrating
software engineering in introductory com-
puting courses. IEEE Softw.,2002, 19(5)
64–71.
18. Michael Davis Defining “Engineer” — How
to Do It, and Why It Matters/Journal of En-
gineering Education, Vol. 85, No. 2. 1996
19. Gary Ford, Norman Gibbs, A Mature Profes-
sion of Software Engineering/Technical Re-
port CMU/SEI-96-TR-004 ESC-TR-96-004
September 1996
20. George Hurlburt and Jeffrey Voas, Software
Is Driving Software Engineering?/ IEEE
Software, January/February 2016, 101-104p
21. P. Bourque and R.E. Fairley, eds., Guide to
the Software Engineering Body of Knowl-
edge, ver. 3.0, IEEE CS, 2014; www.swe-
bok.org.
22. https://www.acm.org/binaries/content/as-
sets/education/se2014.pdf
23. A. Mishra et all, Software engineering edu-
cation: Some important dimensions/Europe-
an Journal of Engineering Education · June
2007
24. Dart, P., Johnston, L., Schmidt, C. and
Sonenberg, L., Developing an accredited
software engineering program. IEEE Softw.,
1997, 14(6), 66–70.
25. Ford, G.A., Progress Report on Undergradu-
ate Software Engineering Education. CMU/
SEI-94-TR-11. Software Engineering Insti-
tute, Carnegie Mellon University, 1994.
26. Moore, M.M., Software engineering educa-
tion. IEEE Softw., 2002, 19(5), 103.
27. Saiedian, H., Software engineering educa-
tion and training for the next millennium. J.
Syst. Softw., 1999, 49, 113–115.
28. Current State of Software Engineering Mas-
ter’s Degree Programs In the United States
Donald J. Bagert and Xiaoyan Mu in Pro-
ceedings - Frontiers in Education Confer-
ence · November 2005
29. V.R. Basilli, “Software Engineering: State of
the Art and Practice,” Software Engineering:
Barry W. Boehm’s Lifetime Contributions to
Software Development, Management, and
Research, R.W. Selby, ed., John Wiley &
Sons, 2007, ch. 8.
30. Capers Jones, Variations in Software De-
velopment Practices, November/December
2003 IEEE SOFTWARE
31. C. Landwehr et al. Software Systems Engi-
neering programmes a capability approach/
The Journal of Systems and Software 125
(2017) 354–364
32. A. Mishra et all, Industry Oriented Ad-
vanced Software Engineering Education
Curriculum, Croatian Journal of Education
Vol: 14 (3/2012), pages: 595-624
33. C. Wohlin *, B. Regnell, Strategies for in-
dustrial relevance in software engineering
36
Освітні та навчальні аспекти програмування
education, The Journal of Systems and Soft-
ware 49 (1999) 125±134
34. Graduate Software Engineering
2009(GSwE2009) Curriculum Guidelines
for Graduate Degree Programs in Software
Engineering, 2009, Stevens Institute of
Technology
35. Н. А Сидоров, Экология программного
обеспечения, Інженерія програмного
забезпечення, Вип.1, 2010, C53-61
36. The ACS Core Body of Knowledge for ICT
Professionals (CBOK), Australian Comput-
er Society Inc, Sydney NSW 2000
37. K. Petersen, R. Feldt, S. Mujtaba, M. Matts-
son, Systematic mapping studies in software
engineering, Proceedings of the .-12th Inter-
national Conference on Evaluation and As-
sessment in Software Engineering, 2008, pp.
1-10.
38. Paulo Sérgio Medeiros Dos Santos, Guil-
herme Horta Travassos Action Research Can
Swing the Balance in Experimental Soft-
ware Engineering.- Advances in Computers
· December 2011, P78.
39. P. Runeson, М. Сase study research in
software engineering, Guidelines and Ex-
amples.- 2012 by John Wiley & Sons, Inc,
P241.
40. Forrest Shull • Janice Singer • Dag I.K. Sjø-
berg Guide to Advanced Empirical Software
Engineering.- Springer-Verlag London Lim-
ited 2008, P394.
41. Basili,V.R, et al, Goal Question Metric Ap-
proach, John Wiley&Sons,1994.
42. Mary Shaw Writing Good Software Engi-
neering Research Papers.- Proceedings of
the 25th International Conference on Soft-
ware Engineering, IEEE Computer Society,
2003, pp. 726-736.
Отримано: 25.05.2022
Про автора:
Сидоров Микола Олександрович,
доктор технічних наук,
професор.
Кількість наукових публікацій у
українських виданнях – 140.
Кількість наукових публікацій у
зарубіжних виданнях – 22.
http://orcid.org/0000-0002-3794-780X
Місце роботи автора:
Національний Технічний Університет
України «Київський політехнічний
інститут імені Ігоря Сікорського»,
факультет інформатики та обчислюваль-
ної техніки, кафедра інформатики та
програмної інженерії, ІПІ, професор.
02000, Київ,
вул. Політехнічна, 41.
Моб. тел.: 067 7980361.
E-mail: nyksydorov@gmail/com
|