Про систему

Ця сторінка присвячена тому ХТО, НАВІЩО і ЯК створював Систему комплексної автоматизації "Оберон". Тому, що з цього вийшло, присвячені інші сторінки цього сайту.

Хто

Перш ніж приступити до формулювання концепції та створення Системи комплексної автоматизації "Оберон", автори протягом 13 років займалися автоматизацією банківських установ та систем традиційними методами (і, наскільки дозволяє судити власна упередженість) в міру сил досягли успіху в цьому.

Традиційних методів, наскільки відомо, два.

Перший полягає в тому, що у складі структури, що автоматизується, створюється підрозділ, який займається побудовою системи автоматизації за повним циклом: від постановки задачі, що включає у тому числі вивчення предметної галузі, та прогнозування напрямів її розвитку, до підтримки користувачів./p>

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

Власний досвід (8 років першим методом та 5 - другим) не дозволяє авторам визначитися, який із методів краще. Швидше вони схиляються до висновку "ОБИДВА ГІРШІ".

Перший метод (власна розробка) теоретично дозволяє створити саме таку систему автоматизації, яка потрібна саме цій установі, бути повновладним власником власної системи автоматизації та оперативно реагувати на виклики, що виникають на ринку. Однак, на практиці в середньостроковій перспективі виявляється, що відірвані від зовнішнього світу і занурені у свій локальний світ, розробники схильні зациклюватися на своїх проблемах і їх вирішенні, повторюватися в технічних рішеннях, і врешті-решт бізнес починає буксувати і відставати від конкурентів. Крім того з'являється адміністративно-суб'єктивний фактор: всім хочеться кар'єрного зростання, а де його взяти? І з часом виявляється, що або програмісти трапляються зубасті і починають диктувати своє бачення розвитку бізнесу об'єкту автоматизації (класична ситуація: собака починає крутити хвостом); або з часом їх "ставлять на місце", і це місце виявляється десь між охороною та технічними службами. Найкращі фахівці при цьому, зрозуміло, розбігаються.

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

Що робити бідному власнику об'єкта автоматизації? Один із авторів якось сформулював своє бачення ситуації так: "Якби я міг однозначно та аргументовано відповісти на це питання, Білл Гейтс точив би в мене в офісі олівці!".

Відтак, після того як побачили справу з обох боків: від програміста до керівника IT-підрозділи великого банку та від рядового розробника до керівника проекту великої софтверної компанії, автори взяли на себе відповідальність спробувати сформулювати та в міру сил проводити власний підхід до рішення Завдання автоматизації.

Навіщо

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

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

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

Як

Спробуємо уявити собі людину(назвем її Програмістом), яка прийшла на незнайомий об'єкт автоматизації із завданнями, аналогічними викладеним вище. Залишимо поки що осторонь вимоги до її професійної підготовки, до того, якими навичками вона повинна володіти, вона має зрозуміти, чого намагаються досягти на об'єкті автоматизації і як цього можна добитися. Через деякий час є перше наближення до розуміння деталей предметної області. Що тепер з цим розумінням робити? Писати аналітичні записки? На UML? А навіщо? Віднести спеціалістам об'єкта автоматизації? І що вони з цим будуть робити? Читати? Ну ну...

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

Тому буде дуже корисно, якщо на другу зустріч Програміст візьме з собою модель, що діє. Модель того, що він виніс із першої зустрічі. Такий собі прототип. Цей прототип може ще не мати половини інформаційних полів, може бути не підключено та не заповнено жодного довідника, не кажучи вже про онлайнову довідкову систему. Але ГОЛОВНЕ з того, що він виніс із першої зустрічі має бути прототиповано. І згодом цей прототип повинен не чутливим чином перейти на робочий комп'ютер прикладного фахівця, поступово доповнюючись функціями та обростаючи довідниками. Згодом будуть виправлені відмінки на екранних формах і додасться онлайнова довідкова система, але це вже не принципово. Важливо, що прикладні фахівці відразу бачать, що розмови, які вони ведуть, не ідуть у світлу далечінь і не повертаються до них у вигляді багатотомних трактатів, які все одно ніхто читати не буде, а відразу перетворюється на щось відчутне, яке можна покрутити і покритикувати, а їх думка буде врахована і програма буде підправлена відповідно до цієї критики.

Як має виглядати інструмент, придатний для створення такого прототипу, що поступово розвертається у повноцінну систему? Насамперед, він має бути одночасно досить простим щоб швидко "зліпити" простий прототип і досить потужним, щоб згодом розгорнутися у повноцінну систему. Він повинен "розмовляти" "мовою" предметної області, щоб людина, занурена в предметну область, не відволікалася на тригери і процедури, що зберігаються, але при цьому давати на виході робочу систему. Він має підтримувати роботу з різними СУБД. Він повинен давати можливість видозмінювати систему у процесі експлуатації без втрати даних та інших катаклізмів. Зрештою, він повинен дозволяти вбудовувати нові можливості.

І саме для того, щоб задовольняти цим та ще деяким іншим вимогам, і створювалася Система комплексної автоматизації "Оберон"

Таким чином, Система комплексної автоматизації "Оберон" є не АСУ у звичному розумінні цього терміна, а інструмент прототипування, створення та розвитку автоматизованих систем.

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

Але це, як писали А. & Б. Стругацькі у неповторному романі "Понеділок починається в суботу", вже зовсім інша історія.

А тим, хто зацікавився, пропонуємо ознайомитися з тим, на яких засадах будувалася Система комплексної автоматизації "Оберон" та що з цього вийшло.