Letyshops

База знаний по программному комплексу

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Идея состоит в следующем:
1) Создание специализированной программной оболочки для формализованного представления знаний о любом программном комплексе.
2) Условие: программный комплекс "сборочного" типа
3) Формат представления знаний (наполнения оболочки):
- рабочие процедуры (активностная модель описания поведения системы)
- иерархия и взаимосвязь объектов системы с привязкой к рабочим процедурам (информационная модель взаимодействия объектов системы)

Вопросы:
1) Насколько актуальна разработка подобной оболочки ?
2) В случае актуальности проекта, будет-ли проект иметь коммерческий успех ?

By ppv on Вторник, Август 01, 2000 - 12:00:

Олег,
Извините, не понял я, зачем всё это, для чего.
Александр

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Александр, представь:
Принципиально новый или плохо тобой изученный старый программный продукт, к тому-же навороченный. Единственное, что ты знаешь- это для чего он предназначен, ну и естественно ты владеешь знаниями в предметной области.
Встает вопрос- как использовать программу для работы?
Что произойдет, если поставить галочку в ЭТОМ поле ?
Когда это что-то произойдет ?
Какими альтернативными способами можно решить ЭТУ задачу ?
При каких условиях ЭТО действие не будет выполнятся ?
Можно бесконечно продолжать список вопросов.
Эти вопросы ежесекундно задают себе(HELPy, специалисту и т.д.) тысячи людей - осваивающих, тестирующих, анализирующих, макетирующих.

Ответ на эти вопросы и есть процесс получения знаний.
Как традиционно передаются знания о программе ?
1) Через инструкции
2) Через преподавателя
3) Путем тыка
4) Через HELP

Это не рационально, очень дорого и долго.
Собственно, у меня сложилась определенная концепция построения оболочки для представления любых знаний о программе. Только не хочется напрасно терять лучшие годы своей жизни.

By Алексей Важнов on Вторник, Август 01, 2000 - 12:00:

Олег,

если не хочется терять лучшие годы - берется Outlook + Exchange Server (для коллективной работы) или только Outlook (для персональной) и с установкой выкачанного из Internet дополнения под названием HelpDesk разворачивается требуемая Вами среда для фиксации сокровенных знаний.
При необходимости можно делать доработки средствами FormDesigner + Visual Basic.

By Аноним on Вторник, Август 01, 2000 - 12:00:

Уважаемые господа! Просветите дилетанта. Как расшифровывается аббревиатура ASAP? Что понимается под этим?
Заранее спасибо!

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Алексей !
Спасибо за совет. Не знаком с указанным продуктом.
Обязательно посмотрю.Не подскажете преварительно формат представления знаний в этом софте ?

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Доброе время суток, уважаемые.

Олег, можете ли поделится результатами знакомства с "указанным продкутом"?

Если вернутся к исходному вопросу
1) Насколько актуальна разработка подобной оболочки ?
2) В случае актуальности проекта, будет-ли проект иметь коммерческий успех?

Разработка актуальна. На моей памяти такое предложение по счету уже не в первом десятке.

Будет ли иметь коммерческий успех... Думаю, что не будет.

Проблема заключается ведь не в том, чтобы разработать комплекст "сборочного" типа и создать описание с помощью оболочки (это дорого, но реально).

Проблема заключается в том, чтобы описание соответствовало комплексу в любой момент времени. Общеизвестно, что любой программный комплекс развивается дополняется. Будет ли оболочка синхронизировать описание с текущим состоянием комплекса?

Если будет вручную, то это ОЧЕНЬ дорого. Такого нет практически ни у кого (есть и исключения, MS и MSDN). В полном варианте (описание дает ответ на все комбинации галочек) нет вообще ни у кого.

По сути, самым полным описанием програмного комплекса являются... все исходные тексты самого программного комплекса. Другое дело, насколько такое описание приемлимо для рядовых пользователей.

Здесь, наверное, надо говорить не столько об оболочке, сколько о новой парадигме программирования. Самоверифицирующиеся и самодокументирующиеся языки и инструментальные системы. Разработки в этом направлении ведутся (язык CLU, например). Но реальных результатов пока не много.

Поэтому для любого разработчика дополнительная "оболочка" - это дополнительные и очень существенные затраты времени, усилий и денег. Скорее всего эти усилия в процессе разработки не окупятся.

Хотя для пользователей наличие некоего MSDN для комплекса является существенным плюсом при приобретении программного комплекса.

By Федор Петренко on Вторник, Август 01, 2000 - 12:00:

Рано или поздно любая компания либо погибнет под натиском конкурентов, либо озаботится своей базой знаний.
Все лучшие головы рано или поздно уходят из компании и уносят с собой все, кроме того, что они оставили в базе знаний. Это конечно же касается и знаний об информационной системе.
Я слышал из личных контактов, что очень хорошо (может быть лучше всего в мире) этот вопрос поставлен в Andersen Consulting.
Для относительно небольших объемов (меньше 100 000 статей) мне кажется можно использовать Lotus Notes. Если это информация о различных know how и просто процедурах использования, то можно ввести, например, два поля "Категория" и "Ключевое слово" и начать стихийно писать все виды статей в одну базу. Когда их станет около 1000 следует провести ревизию списка категорий и ключевых слов и заморозить некоторый набор. Все новые категории и ключевые слова вставлять уже по письменному запросу с обоснованием.
Если это информация о технических компонентах (таблицах, хранимых процедурах, экранных формах, отчетах и т.д.), то для их описания лучше использовать не просто документы общего вида, а со стандартными полями, например, для таблицы это могут быть Общие характеристики, Поля, Индексы, Связи, Триггеры, Права доступа, Комментарии.

По поводу коммерческой оправданности. Если система делается на продажу, то конечно нужно провести какое-никакое маркетинговое исследование и по крайней мере составить бизнес план, посчитать NPV и т.д.
Если система создается компанией для себя, то я считаю что база знаний оправдана всегда. Конечно главные убытки от отсутствия базы знаний лежат в области общего управления, например можно смело предполагать, что при отсутствии базы знаний как минимум 50% инвестиционных решений будут приняты ошибочно (вот и считайте убытки). Но это касается базы знаний по управлению. Что касается базы знаний по системе, то представьте: ваши конкуренты ввели новую модель скидок, а вы не знаете как механизм скидок работает в системе и как его видоизменить - покупатели уходят к конкуренту, а консультант требует 0.5 MUSD за то, чтобы разобраться и модифицировать систему, другой пример, система начинает неправильно учитывать балансы взаиморасчетов, вы не знаете как это работает и как это исправить, клиенты не довольны, а консультанты требуют все того же и т.д. Это даже слишком сложные примеры, давайте проще, допустим на какой-то момент в системе реализована только возможность отгружать заказ целиком, а вы решили ввести возможность частичной отгрузки в случае частичной оплаты- это будет практически невозможно сделать, если в течение того времени как система создавалась-модифицировалась-внедрялась не велась полноценная документация как техническая, так и функциональная. И это только разовые структурные проблемы, не считая ежедневных избыточных затрат на поддержку пользователей, обучение новых сотрудников, исправление ошибок и т.д.

By Алексей Важнов on Вторник, Август 01, 2000 - 12:00:

Здравствуйте, господа!

Я на некоторое время выпал из Вашего общения из-за жуткой запарки на работе, извините.

Федор Петренко очень подробно описал процедуру итеративного формирования внутрикорпоративной базы знаний с использованием Lotus Notes. Предлагая связку Exchange + Outlook я имел в виду именно эту технологию.

Олегу Смирнову:
Формат представления знаний - электронная форма (типа почтового сообщения), содержащая поля и произвольный текст.

По мере накопления записей производится модификация этой формы, а, затем, возможно какая-то обработка на встроенном языке - Lotus Script или Visual Basic.

Дешево и сердито. Но, как мне кажется, на первом этапе этого более чем достаточно.

By А.Фирсов on Вторник, Август 01, 2000 - 12:00:

Тому, кто спрашивал про ASAP:
As soon as possible/По возможности скорее.
Рекомендую пользоваться www.acronymfinder.com

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Господа !
У меня к сожалению не было возможности познакомиться с вышеуказанными продуктами, но я предлагаю совершенно новую концепцию:

1) Считаю, что просто в группу полей, даже со ссылками друг на друга невозможно запихнуть знания о программе, необходим свежий взгляд на вещи. Свежесть заключается в том, чтобы проследить за ходом своих рассуждений при освоении программного продукта и затем попытаться построить модель ответа на возникающие вопросы с помощью некоей оболочки. Модель может быть представлена в виде, который я описал в первом сообщении. Насколько мне известно, таких оболочек пока не разработано.
2) Справедливо замечено, что наполнять оболочку чрезвычайно дорого. Естесственно, автоматически знания генерится не могут при обновлении программ, для этого оболочка должна быть умнее разработчика. Давайте поразмышляем :
- Костяк описываемой программы довольно неизменен, меняется (добавляется)функционал.
- Первоначальный объем знаний должен быть набит инженерами знаний , от этого никуда не уйдешь.
- По новым и меняющимся знаниям : почему-бы не допустить идею, что эти знания могут заводиться широким кругом специалистов с дальнейшей экспертизой теми-же инженерами знаний ? Какой интерес у специалистов тратить свое время на эту неоплачиваемую работу ? Во-первых, честолюбие (знания имеют автора), во-вторых, мысль о том, что ДРУГИЕ знания будут заложены другими специалистами (кооперация , если хотите).А это уже снежный ком самоорганизации базы знаний.

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Делать базу знаний в произвольной форме - получится интернет-подобная структура в разных форматах с чудовищно сложным поиском.

Делать базу знаний с заданным форматом - база знаний действительно становится неполной и достаточно быстро костенеет и устаревает.

Насколько я знаю, других альтернатив пока нет.
Может поэтому и нет коммерческих предложений?

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Какой интерес у специалистов тратить свое время на эту неоплачиваемую работу ? Во-первых, честолюбие (знания имеют автора)

Это конечно да. Но честолюбия авторов недостаточно, чтобы гарантировать качество и адекватность знаний, заложенных в базу знаний.

Если достаточно большой процент знаний будет неадекватным, то использование (поиск в) такой базе знаний теряет смысл.

во-вторых, мысль о том, что ДРУГИЕ знания будут заложены другими специалистами (кооперация , если хотите).А это уже снежный ком самоорганизации базы знаний

Это тоже да. Но пороговое число специалистов должно быть достаточно большим.

Например, эти форумы. Тут и честолюбие и конкуренция. Однако самоорганизации пока не происходит.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Сергей, опять с тобой согласен : есть масса знаний, которые невозможно формализовать, или можно формализовать, но тогда нужно будет создавать базу знаний по использованию базы знаний (без тавтологии не получается).
Решение простое - жестко формализуемые знания представляются по формату, плохо формализуемые знания представляются в некотором лингвистическом формате , но с примерами использования из практики. Кстати так устроены многие базы знаний.
И еще : я не претендую на построение экспертной системы, это совсем другая песня.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

По поводу самоорганизации базы знаний - это контролируемый и направляемый процесс, форум-же контролируется , но не направляется.

By Александр Пыпин on Вторник, Август 01, 2000 - 12:00:

Кем или чем контролируемый и направляемый ?

By Wall on Понедельник, Сентябрь 11, 2000 - 11:22:

по поводу терминов: посмотрите http://appost.lanit.ru/vyazovoy/gloss.htm - там много чего есть.

By Аноним on Среда, Ноябрь 08, 2000 - 16:47:

Сама по себе оболочка вряд-ли кому нужна, другое дело, за данные в ней платить можно. По мимо функционала софта крайне интересны оценки по стоимости владения, или раскладка по статьям. В этом случае, я мог бы сравнить свою структуру затрат (стоимость владения) с какой-то средней, или лучшим образцом. Направление нужное и стоящее. Время оболочек прошло, интересны сервисы. (Лет 7 назад создаваля софт для ЖД и др. расписаний, программы продавались с расписанием, рассылались обновления, и где это сейчас? Интернет на дворе!)

By Snake on Четверг, Ноябрь 09, 2000 - 09:22:

Уважаемые!!! все до истерики элементарно. Сектор пользователей? - Клиенту? - не надо. Я уже говорил, что клиенту до фени знания о программном комплексе. Все знания для него сводятся к тому Сколько я получу навара в результате внедрения или сэконономлю. ПОЛЬЗОВАТЕЛЮ? - наверное, хотя я не встречал бухгалтера которому нужно было что то больше чем книжка по ПО. Разработчику? - кто то был прав сказав про авторское самолюбие, ну разве что что бы содрать оттуда чяго нибудь. Как справочная информация для выбора системы - наверное, только кто платить будет. ВЫВОД - интересно, но никто платить не будет и соответсвенно никому не нужна. Но если у Вас много денег и Вы хотите таким образом повысить конкурентоспособность может быть, но подумайте о соотвествии "цена - качество" С уважением

By Олег on Пятница, Ноябрь 17, 2000 - 09:02:

Snak-у. Если я правильно понял, то диспут идет не просто о базе знаний (свалка правил), а о системе управления этими знаниям (правилами), а т.к. правила существуют во всех областях, то подобная система пришлась бы кстати (и для разработчика и для пользователя-специалиста-в-своей-области).

By Snake on Пятница, Ноябрь 17, 2000 - 10:19:

Олегу.. Мне кажется в таком виде продажа ПО не будет иметь серьезного успеха, Но есть смысл рассмотреть другой вариант: сформировать базу данных, систему управления этими знаниями. Далее организовать на этой основе в Интернете WEB узел, обеспечить его поддержку и продавать доступ в него? например в виде абонемента на месяц, на неделю... И если хорошо структурировать данные таким образом что бы: КЛИЕНТ мог найти какую то справочную информацию, облегчающую его участь, РАЗРАБОТЧИК мог содрать что нибудь новенькое у конкурента, КОНСУЛЬТАНТ оценить для себя тот или иной вариант системы, ПОТЕНЦИАЛЬНЫЕ КЛИЕНТЫ могли бы оценить новинки... То я думаю отбою не было бы... С уважением

By Пересыпкин Роман on Вторник, Ноябрь 21, 2000 - 18:10:

мне кажется что объем работ по созданию и поддержке актуальности такой базы сравним с затратами на сам софт. может этот ресурс на софт и потратить

By Афонин Виктор on Воскресенье, Февраль 11, 2001 - 20:51:

Коллеги,

а зачем избретать велосипеды? Все это уже давно, на мой взгляд систематизировано и реализовано в RUP (Rational Unified Process).

By Афонин Виктор on Четверг, Март 08, 2001 - 00:55:

Что-то так никто и не продолжает данную дискуссию... Или мое высказывание оказалось той жирной точкой или чертой, которая подвела итог дискуссии?

By Аноним on Вторник, Май 22, 2001 - 14:59:

Афонину Виктору:
Наверное все дело в том, что тема поднятая в дискусии скорее философская, чем программно-технологическая,
Насколько я понял речь идет о попытке формализовать процесс творчества, создать систему мониторинга за СОЗДАТЕЛЕМ программы, что-то вроде ZIP-архиватора, но для системы знаний,творческим процессом
(мнда, забавно)

 

 

Реклама: