(С) 2003,Кабанов Олексій (БТР)
mailto: [email protected]

/

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

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

Але, перш за все, хочеться висловити подяку величезному безлічі людей, завдяки підтримці яких я не закинув цю ідею на початку шляху, не розтягнув на десятки років, і не пішов продавати на ринку огірки або лак для нігтів. Всіх я тут навряд чи згадаю, місця для статті інакше просто не залишиться, назву лише Мальцева Бориса (більш відомого під ніком той) і Александрова Олександра.

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

  1. Етапаналізу, на якому відбувається збір пропозицій, вимог, побажань, аналогій, фактів, прикладів, ескізів, сценаріїв і т . п.
  2. Етапуправління варіантами системинеобхідний, щоб не потонути в яку накопичує аналітичному матеріалі. Вимоги розбиваються на групи за важливістю, терміновості, трудомісткості і т.д. - В залежності конкретної ситуації кількість груп може змінюватися, і ці зміни так само управляються на цьому етапі.
  3. Етапконструюваннязнаменують собою початок синтезу перших обрисів системи. Тут відбувається розробка варіантів архітектури системи, концептуальних моделей системи, діаграм взаємодії підсистем, блоків і модулів і т.п.
  4. Етапуправління випусками варіантів системивключає в себе роботи з визначення послідовності наповнення системи функціональністю на рівні розроблених на етапі конструювання елементів системи.
  5. Етаппроектування- призначений для розробки структур метаданих різних модулів, блоків і підсистем та алгоритмів їх взаємодії між собою
  6. Етапуправління збірками випусків варіантів системидає можливість визначити, що саме потрібно включити в працюючу систему, які об'єкти опрацьовані досить детально, щоб їх реалізувати і надати для експлуатації
  7. Етапреалізаціїполягає в розробці об'єктів метаданих та алгоритмів їх дії, кодуванні в різних платформах, тестуванні роботи об'єктів, документуванні різних аспектів роботи реалізованих об'єктів, що стосуються використання, адміністрування та опису застосованих технічних прийомів реалізації
  8. Етапуправління редакціями зборок системипредставляє собою визначення конкретного наповнення надається користувачеві працюючої системи. Інакше кажучи, включення, оновлення і виключення різних редакцій структури, описів та вихідного коду об'єктів до/з складання системи. А, крім того, підготовка презентацій і демонстраційних матеріалів, визначення актуального стану документації різних рівнів, найбільш точно відповідної поточному стану наданої користувачам системи
  9. Етаппрезентацій і демонстрацій замовникам і користувачам системиприпускає перший показ працездатності змінених частин системи, а також оформлення протоколів презентацій і демонстрацій, оформлення актів за зауваженнями і пропозиціями користувачів.
  10. Етапнавчання користувачіввключає в себе підготовку планів навчання, матеріалів, необхідних для навчання, власне навчання і перевірку засвоєння знань і навичок володіння системою користувачами.
  11. І, нарешті,етап управління змінами в системе, включає в себе адміністрування, введення в експлуатацію нових і змінених об'єктів системи, вивід з експлуатації застарілих і замінених об'єктів системи, в якій безпосередньо працюють користувачі


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

Технічні завдання на систему
Тестові приклади
Конструкторська документація
Проектна документація
Вихідні коди системи
Описи структури баз даних системи
Шаблони баз даних системи
Виконувані модулі системи
Документація користувача
Документація системного адміністратора
Документація адміністратора баз даних
Документація адміністратора системи
Документація демонстратора
Документація викладача
Документація прикладного програміста
Документація системного програміста
Пакети презентацій та матеріали демонстрацій для замовників і користувачів
Плани демонстрацій і випробувань
Протоколи демонстрацій і випробувань
Результати тестування
Акти усунення зауважень

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

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

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

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

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

Ось тут то і народжується ідеологія Knowledge Management - управління знаннями. А оскільки кожна концепція управління найкращим чином проявляється в регламентованих, формальних процесах, що враховують всі правильні стадії і етапи руху від якомога раннього входу в управління, і закінчуючи якомога більш чутливими індикаторами відхилень від проведення правильно задуманого процесу, то і бажання автоматизувати управління знаннями не здається дивним. Так ми приходимо до ідеї KMS (knowledge management system) - системам управління знаннями.

Вважаю людям, що читають цю статтю так чи інакше відомі абревіатури ERP, BPR, CALS, і усілякі CRM, SCM, TQM, QSM, HRM, MRP, і всілякі інші ... Management ..., ... Planning ... і ... System .... Напевно майже кожному щось говорять і всілякі SADT, OODT, MSF, RUP, XP і багато-багато інших ... Modelling ..., ... Solution ..., ... Process ... і ... Technical Design ....

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

Ну і, власне, пара пару слів сказати про KM в тому вигляді, як це вдалося прочитати в скупих рядках прес-релізів на комерційні KM-системи, та в небагатьох, важко-(для мене)-перекладної інформації про самої концепції KM. Що вдалося зрозуміти? По-перше, комерційні реалізації КМ-систем спрямовані в основному на "здобич" знань із загальнодоступних джерел (Data Mining) на підставі різних правил, шаблонів, запитів і т.п. Власне питань роботи з цими знаннями приділяється не там багато уваги. Можливо, вважається цілком достатньо існуючих засобів комунікацій та впорядкування знань? Можливо, що просто я сам заморочуюсь у вигадуванні фішок і рюшечек? Сподіваюся, що не одному мені хочеться дещо додати до процесу впорядковування творчих пошуків. Щоб це дізнатися залишилося розглянути, яку б систему я бажав бачити на робочому місці "будівельників корпоративних інформаційних систем".

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

Чого найчастіше не вистачає на форумі? Ну, наприклад, можливості привести діаграму. А іншому - внести до неї зміни. А десята - по діаграмі написати виконуваний код і привести його для дослідження. А сто двадцятого й сьомого подивитися на код і в рядку 6427 методом зворотних посилань повернутися до спочатку поставленої аналітичної задачі, яку цей рядок покликана вирішити. А чотири тисяча дев'ятсот шістдесят шостого - внести пропозицію про додавання в сценарій алгоритму додаткової умови. А сім тисяч сто п'ятьдесят другому це пропозиція реалізувати в 75 редакції цього об'єкта. А N +3- му учаснику включити цю редакцію в збірку N 17 КІС. А N +9- ий продемонстрував нову особливість системи ... І так далі, від початку і до кінця, цілком відповідаючи регламентам управління життєвим циклом КІС.

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

А поки - до наступної статті.


Стаття отримана: Клерк.Ру

Детальніше »