Концепція програмного сервісу



Стаття | Article    

Download

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

Ключові слова: програмне забезпечення, розробка, сервіс, провайдер, замовник

Software services concept

Article contains description of software services concept as continuous and phaseless evolutional process of providing different software services which replace standard software life cycle (planning, coding, testing, evolution, maintenance) and support processes (payment, integration, rent, client-provider interaction)

Keys: software, development, service, provider, client

Volodymyr Khmeliuk - Senior Lecturer, NTUU «KPI»

Illia Maier, Mykyta Ozerakin, Oleksandr Tymoshenko –students, NTUU «KPI»

Ukraine, Kyiv

Завдяки планомірному розвитку та досягненням технічного прогресу багато промислових галузей переходять від продуктових політик до сервісних. Так, наприклад, замість того, щоб купити супутниковий телефон у певної компанії, вкласти з нею договір та оплачувати щомісячну абонплату (продуктовий підхід) – ви маєте змогу купити телефон будь-якого виробника на ваш розсуд, обрати компанію, що буде вам надавати послугу зв’язку (сервіс) і надалі купувати додаткові послуги у цієї компанії за необхідності, орієнтуючись лише на власні потреби та товщину гаманця. Або ж замість купувати собі електрогенератор, ви можете встановити собі лічильник використання електроенергії і платити за сервіс надання доступу до електричних мереж міста згідно обсягів використаної електроенергії та тарифу. Ваш автомобіль теж ймовірно обслуговується в сервісному відділі певного автосалону. Подібних прикладів існує безліч.

І, хоча сфера інформаційних технологій розвивається найбільш динамічно та зазвичай є форпостом запровадження різноманітних нововведень та новаторських рішень, з переходом від продуктового підходу до сервісного не все так гладко. Так в частині «хард» давно вже практикується надання сервісів оренди серверних потужностей, сервісів хмарних містилищ та хмарних обчислень, сервісів послуг інтернет-провайдерів, тощо. А от в частині «софт», тобто програмного забезпечення, – повна тиша. Ви маєте змогу лише купити програмний продукт, або замовити його розробку, що по суті одне й те ж. Правда деякі великі компанії розробники ПЗ, наприклад Microsoft, все ж намагаються запровадити ідею надання послуг використання ПЗ (той же Office365), але такі виключення поодинокі і лише підтверджують сумне правило.

І, оскільки ще не існує типових сервісів програмного забезпечення (1),спробуємо з’ясувати, якими мають бути такі сервіси і яким вимогам вони мають задовольняти. Отож, основним видом сервісу програмного забезпечення (СПЗ) має стати сервіс безперервної розробки ПЗ (що має замінити собою весь життєвий цикл ПЗ: планування, розробку, тестування, модифікацію, супровід, оплату, тощо). Бо, хоча деякі імениті компанії-розробники наголошують, що вони надають сервіс ПЗ, насправді вони надають лише можливість вибору однієї з продуктових політик використання вже існуючого продукту.

Спробуємо уявити, як би могла виглядати типова взаємодія замовника послуги ПЗ (клієнта сервісу) та розробника ПЗ (в даному контексті провайдера сервісу):

А) Я клієнт:

Я реєструюся на сайті сервісу ПЗ як Замовник. Я описую функціонал, який я хочу отримувати від цільового ПЗ, орієнтовні терміни виходу на робочий режим ПЗ, допустиму вартість умовної години розробки та інші необов’язкові характеристики сервісу. Мою заявку зі статусом «Пошук виконавця» бачать всі зареєстровані розробники ПЗ (провайдери). Зацікавлені провайдери пропонують свої послуги (сервіс ПЗ). Обговорення деталей ведеться тут-же на сайті. В мене є можливість побачити контактні дані провайдерів та зв’язатися з ними безпосередньо для обговорення деталей та нюансів взаємодії. Після вивчення пропозицій я обираю провайдера та замовляю його послугу ПЗ, заключаючи з ним Договір та закриваючи цим свою заявку. З цього моменту мені надається сервіс ПЗ. Я оплачую обумовлену грошову суму на рахунок провайдера, якщо це передбачено (2). Далі в CS (3) я створюю початкові вимоги до ПЗ. Провайдер оцінює мої вимоги в умовних трудовитратах. Я маю змогу деталізувати вимоги, змінити, відмінити, перевпорядкувати, тощо та запропонувати свою вартість реалізації кожної з вимог. Після змін увимогах і я і провайдер можемо змінити власну запропоновану ціну реалізації вимог. Після певного ітеративного процесу узгодження вимог та їх вартості (так званий аукціон вимог) я підтверджую готовність обраних вимог до реалізації. Провайдер підтверджує факт запуску вимог у розробку. Після реалізації вимоги до ПЗ провайдер повідомляє мене про реалізацію вимоги в новій версії ПЗ, яка автоматично розгортається у мене підсистемою розгортання (згідно налаштувань розгортання та політик підтримки версійності ПЗ). Я підтверджую виконання вимоги в повному обсязі після перевірки функціонування ПЗ. В цей момент з мого рахунку списується оговорена грошова сума а вимога вважається закритою. В процесі моєї взаємодії з провайдером можуть виникати нові вимоги, вимоги можуть ієрархічно розбиватися на дрібніші, об’єднуватися, відмінятися і т.д. згідно алгоритму життєвого циклу вимог. Одними з підвидів вимог будуть вимоги на виправлення помилок, покращення або зміну функціоналу, документування, створення навчальних матеріалів та інші. Надання сервісу провайдером припиняється за двосторонньою згодою, або в випадках передбачених укладеним Договором. Типовим варіантом є нескінченне надання послуги. Переваги, які я отримую від використання концепції програмного сервісу:

$-$ можливість доступу до сервісу ПЗ за допомогою різних робочих обчислювальних машин (ноутбук, смартфон);

$-$ механізм пошуку та конкурсного вибору провайдера сервісу ПЗ;

$-$ середовище для спілкування з провайдером щодо замовленого сервісу ПЗ;

$-$ мінімізацію часу та зусиль на створення технічного завдання на розробку ПЗ, методики перевірок та тестувань та іншої супутньої документації;

$-$ можливість формування поточних версій деяких паперових документів в будь-який час (наприклад ТЗ, звіти, тощо);

$-$ прозорість виконаних робіт провайдером згідно вимогам;

$-$ можливість надгнучкої зміни вимог до ПЗ;

$-$ систему встановлення пріоритетів реалізації вимог узгоджену з провайдером;

$-$ можливість та середовище обліку помилок та відстеження їх виправлення;

$-$ володіння та доступ до містилища поточних напрацювань (вихідні коди, зкомпільовані модулі, документація, тощо);

$-$ можливість використання професійного ревізора оцінок реалізації вимог до ПЗ;

$-$ можливість повного або часткового залучення зацікавлених осіб в процес розробки зі сторони замовника згідно обраної рольової політики в межах надання сервісу ПЗ;

$-$ спрощення розгортання та оновлення ПЗ;

$-$ своєчасність та оперативність оплати робіт виконаних провайдером;

$-$ відстеження та планування бюджету на сервіс ПЗ;

$-$ можливість зміни провайдера в будь-який час без втрати існуючих напрацювань та історії змін вимог до ПЗ;

Б) Я провайдер:

Я реєструюся на сайті сервісу ПЗ як Провайдер. Я вказую профільні предметні області (в яких я маю певні напрацювання та/або конкурентні переваги), посилання на інформацію по реалізованим мною проектам, кваліфікацію та склад команди розробки та супроводження ПЗ, орієнтовну вартість години надання СПЗ, тощо. Мій профіль провайдера разом з рейтингом, відгуками та іншими оцінками бачать як всі зареєстровані клієнти СПЗ так і інші розробники ПЗ (провайдери). Зацікавлені клієнти звертаються до мене з метою уточнення деталей надання СПЗ для можливої подальшої співпраці. Інші провайдери мають змогу звернутися до мене як до співвиконавця з метою доручити мені виконання певних робіт в межах їх власного СПЗ (тобто реалізується платформа пошуку виконавців робіт, але з урахуванням їх планової зайнятості та інших факторів). В мене є можливість побачити контактні дані клієнтів (якщо вони не вказали зворотного) та зв’язатися з ними безпосередньо для обговорення пропозиції по цільовому СПЗ. Після обговорення пропозицій я вкладаю договір на надання СПЗ з клієнтами або іншими провайдерами. Я розпочинаю уточнення початкових вимог замовника до ПЗ за допомогою механізму «аукціон задач» на базовому рівні (тобто до рівня достатнього для планування початкових робіт). Після підтвердження клієнтом починаю виконання робіт по реалізації вказаних вимог. Після виконання вимоги очікую оцінки клієнта на відповідність реалізації. В разі підтвердження клієнтом повного виконання вимоги проводиться фіксація в системі інформації про елемент оплати (фізичне перерахування коштів з таким обліком напряму не зв’язане). Подальші вимоги до ПЗ з’являються в системі в процесі надання СПЗ. Вони можуть генеруватися замовником або розробником з обов’язковим затвердженням зацікавленими сторонами. Переваги, які я отримую від використання концепції програмного сервісу:

$-$ можливість доступу до сервісу ПЗ за допомогою різних робочих обчислювальних машин (ноутбук, смартфон);

$-$ механізм пошуку клієнтів або генеральних підрядників для сервісу ПЗ;

$-$ середовище для спілкування з клієнтами щодо сервісу ПЗ, що надається;

$-$ мінімізацію часу та зусиль на створення технічного завдання на розробку ПЗ, методики перевірок та тестувань та іншої супутньої документації;

$-$ можливість формування поточних версій деяких паперових документів в будь-який час (наприклад звітність по виконанню робіт, часові графіки, іншу інформацію необхідну для подальшого планування та виконання робіт);

$-$ можливість надгнучкої зміни вимог до ПЗ;

$-$ систему встановлення пріоритетів реалізації вимог узгоджену з клієнтом;

$-$ можливість та середовище обліку помилок та відстеження їх виправлення;

$-$ можливість легкого залучення до виконання робіт інших провайдерів СПЗ в якості підрядників;

$-$ спрощення розгортання та оновлення ПЗ;

$-$ можливість передачі клієнта іншому провайдеру (за згоди клієнта) без втрати існуючих напрацювань та історії змін вимог до ПЗ;

$-$ відстеження та часткове прогнозування фінансових надходжень;

$-$ гарантування оплати виконаних робіт клієнтом незалежно від факту повної реалізації вимог у випадку зміни вимог клієнтом, або при припиненні робіт з ініціативи клієнта;

$-$ гнучкі механізми прогнозування та відстеження часових термінів реалізації вимог, задач, робіт, тощо;

$-$ мінімізація бюрократичних витрат;

$-$ значне підвищення взаєморозуміння з клієнтом та максимальне уникнення конфліктних ситуацій;

$-$ реалізація процедур та механізмів можливого вирішення конфліктів за допомогою залучення третьої сторони;

$-$ середовище тісної інтеграції зовнішніх систем розробки та супроводження ПЗ клієнтів в спеціалізовані АРМ провайдера;

Впровадження концепції сервісу програмного забезпечення в життя передбачає проведення низки організаційних заходів, розробки нових та уточнення існуючих методологій розробки та супроводження ПЗ, а також створення програмного забезпечення для підтримки середовища функціонування бізнес-площадок надання СПЗ.

Першою референсною системою підтримки СПЗ є програмна система CleanSlate, що розробляється за участі студентів та викладачів НТУУ «КПІ» та буде детально розглянута в низці наступних тематичних публікацій.

(1) Під сервісом програмного забезпечення СПЗ надалі будемо розуміти повний комплекс робіт з підтримки життєвого циклу ПЗ в поєднанні з фінансовими аспектами розподілений в часі

(2) Слово «prepaid» можна перекласти як «передплата». Якщо коротко, prepaid — це спосіб розрахунку з провайдером послуги. Традиційно існують два варіанти оплати надання послуг: кредитний і дебетний. Якщо користуєшся послугою, а потім здійснюєш оплату рахунків що надійшли — це кредитна система. Дебетна система початково передбачає наявність на вашому рахунку певної суми. Наприклад, авансову форму розрахунку можна віднести до дебетових систем: Ви кладете на рахунок певну суму і після цього її витрачаєте

(3) CS – абревіатура референсної програмної системи підтримки СПЗ CleanSlate, що розробляється за участі студентів та викладачів НТУУ «КПІ»

Перелік посилань

$1.$ Microsoft Office 365 [Електронний ресурс] – Режим доступу до ресурсу: https://products.office.com/en\-us/office\-365\-personal.

$2.$ Лармен К. Scaling Lean & Agile Development: Thinking and Organizational Tools forLarge-Scale Scrum / Креіг Лармен., 2008. – 368 с. – (1-ше). – (978-0321480965).

$3.$ Андерсон Д. Kanban: Successful Evolutionary Change for Your Technology Business / Девід Андерсон., 2010. – 278 с. – (978-0984521401)

$4.$ Кніберг Г. Scrum and XP from the Trenches / Генрік Кніберг., 2007. – 142 с. – (2-ге). –(978-1-4303-2264-1).

May 20, 2017