Статья: Системы управления знаниями и непрерывное управление жизненным циклом корпоративной информац

<p>Долгое время, занимаясь вопросами создания информационных систем различного
масштаба, трудно не задумываться над системными вопросами, типа &quot;а каким
это должно бы быть в идеале?&quot; Постепенно проникаясь знаниями из всевозможных
предметных областей, да понемногу осваивая накопленный опыт управления жизненным
циклом информационных систем, возникло некоторое представление о том, как построить
эффективную информационную систему для тех, кто строит информационные системы.</p>
<p>На эту тему существует огромное множество работ самого разного масштаба. Боюсь,
я даже не имею представления о подавляюще большей части знаний, накопленных
в этой отрасли. Тем не менее, возьму на себя ответственность описать то, что,
рождаясь в муках последние два года, начало оформляться в некий единый материал.</p>
<p>Но, прежде всего, хочется выразить благодарность огромному множеству людей,
благодаря поддержке которых я не забросил эту идею в начале пути, не растянул
на десятки лет, и не ушел продавать на рынке огурцы или лак для ногтей. Всех
я здесь вряд ли упомяну, места для статьи иначе просто не останется, назову
лишь Мальцева Бориса (более известного под ником ТоТ) и Александрова Александра.
</p>
<p>Итак, чтобы как-то подступиться к теме, начну с описания жизненного цикла КИС
(корпоративной информационной системы). На мой взгляд, он выглядит следующим
образом.</p>
<ol>
<li> Этап анализа, на котором происходит сбор предложений, требований, пожеланий,
аналогий, фактов, примеров, эскизов, сценариев и т.п.</li>
<li> Этап управления вариантами системы необходим, чтобы не утонуть в накапливаемом
аналитическом материале. Требования разбиваются на группы по важности, срочности,
трудоемкости и т.д. - в зависимости конкретной ситуации количество групп может
меняться, и эти изменения так же управляются на этом этапе.</li>
<li> Этап конструирования знаменуют собой начало синтеза первых очертаний системы.
Здесь происходит разработка вариантов архитектуры системы, концептуальных
моделей системы, диаграмм взаимодействия подсистем, блоков и модулей и т.п.</li>
<li> Этап управления выпусками вариантов системы включает в себя работы по определению
последовательности наполнения системы функциональностью на уровне разработанных
на этапе конструирования элементов системы.

Читать всю статью: http://www.klerk.ru/soft/1c?1880

Да, пожалуй тема предыдущего обсуждения явно не мобилизует на серьезный разговор... Еще раз. Хотелось бы все-таки обсудить статью
http://www.klerk.ru/soft/1c/?1880
Я понимаю, статья бестолково написана, материал жутко сырой, возможно даже основные тезисы не вылавливаются из смутного потока мыслей...
Но разве не в наших интересах внести в эту тему прояснение?
Еще раз даю название. По частям. Тезисно. С вопросами.
Тезис 1. Жизненный цикл Корпоративной Информационной Системы. Ну кто из нас с ним не сталкивается? Кто из нас не имеет проблем с отдельными его частями? У кого нет вопросов и идей относительно того, какой он есть и каким он должен быть в идеале?
Тезис 2. Непрерывное управление ЖЦ КИС. Ну, просто управление я опускаю, по скольку оно есть неотъемлемое свойство самого ЖЦ. Речь именно о непрерывности. Все эти самые стандарты ИСО 9001:2001, ТСКФ, системы менеджмента качества это и есть непрерывное управление жизненным циклом бизнеса, процесса, технологии и т.д. Почему мы готовы делать системы для других и не готовы хотя бы проделать анализ того, какая система облегчила бы жизнь нам самим?
Тезис 3. Управление знаниями. Собственно вот этот тезис и является на мой взгляд дискуссионным. Лично я полагаю, что 80% работы коллективных мозгов протекает сквозь дыры в коммуникациях. Даже в локальной сети родной фирмы лежит такая масса интересного, которую я упускаю. А когда берешь в руки какую-то конфигурацию, обязательно найдется масса мест, в которых родившийся вопрос "зачем сделано вот это и вот так" не дает покоя, пока не перепишешь код раз пять и после длительных оптимизаций, презентаций и обсуждений не вернешься к тому же что и было, но уже понимая зачем и проклиная разработчика, поленившегося написать аналитический комментарий
Тезис 4. Если предыдущий тезис все-таки получает определенное согласие, то вот вам еще один спорный тезис - а не выходит ли так, что система управления знаниями с целью непрерывного управления жизненным циклом КИС помогла бы нам сделать качественный скачок, резко сократить издержки и увеличить прибыли?
И главная цель статьи это анализ тезиса 4. Какой идеальный инструмент нам необходим? До какой степени нужно охватить жизненный цикл КИС? Может быть кому-то достаточно RAD? Может быть, кому-то достаточно BPM/ERM? Может быть правильный выход это все-таки RUP? Или XP?
А что, ни у кого нет вопросов по этим методологиям? А может быть наоборот, у кого-то есть ответы?

"тихо, сам с собою я веду беседу" :-)

БТР
Я бы попросил воздержаться от столь объемных постингов.

Удалил, потому как читать невозвожно.
training1C Абсолютно прав.

БТР, так и хочется закричать громко и надрывно... "Да! Да! Да! Именно этого и не хватает..." А еще не хватает времени на банальные рутинные операции просто откомментировать собственные же тексты ... (Но это действительно предсмертное ржание загнанного коня... ;) )

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

Почему мы готовы делать системы для других и не готовы хотя бы проделать анализ того, какая система облегчила бы жизнь нам самим?

Честно говоря, не встречал систем управления научно-исследовательскими разработками, где, кроме расплывчатого ограничения предметной области, при старте не известно практически ничего: ни конкретных выходных объектов, ни понятий, которые возникнут в процессе работ, ни ни методов исследования... "Управление знаниями"... Хм... Может, для начала, определить это понятие в "целях данной конкретной задачи" (ну, почти как "в целях данной главы налогового кодекса" :) )

P.S. Жаль, что встреча так и не состоялась, но ведь ещё не вечер :)

Знания действительно систематизировать нужно, в хаотичном состянии они увы почти ничего не стоят. Но позвольте задать несколько глупых вопросов (умным можно не читать):
1. В этапах постоянно упоминается слово "варианты". Это значит разработка сразу нескольких направлений или только дробление на блоки? А на каком этапе возникает единая концепция, т.е. линия поведения, которая развивается в уже определенном направлении.
2. Предполагаетя ли законченность каждого этапа до наступления следующего или возможна параллельность?
3. Судя по описанию твоего отношения (предпочтений) к разработке, как один из моментов закладывается экстремальное программирование. Так?
4. Вполне реально предположить, что современная аппаратура стоит далеко не на всех предприятиях. Так что? Предполагается развивать несколько версий для предприятий с разной степенью оснащенности? Или они будут лишены такой радости?

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

БТР, анонимное выссказывание принадлежит мне.

Спасибо Djudit. Начну по-порядку.
1. Варианты здесь подразумевают матрицу, где по горизонтали расположены подсистемы (список открыт и уникален для каждой КИС, но, например можно привести подсистемы управления сбытом, управления поставками, управление производством, транспортная и складская логистика, управление финансами и т.п.), а по вертикали расположены варианты функциональной реализации подсистем - базовая, стандартная, профессиональная, отраслевая, заказная, этот список тоже является открытым, хотя он и более важен для дальнейшего функционирования и его изменение ведет к весьма глобальным последствиям.
Что касается единой концепции, то она и заключается в модульности и вариативности.
2. Нет, как таковой законченности этапов не предполагается. Предполагается именно параллельность, и, при этом, непрерывность работ на каждом этапе. Ведь речь идет о непрерывном процессе создания новых вариантов, выпусков, сборок и редакций КИС для старых и новых клиентов. Собственно результат выполнения бизнес-процесса, включающего все эти этапы - это выпуски (1, 2, 3,...), состоящие из сборок (1.01,1.02,...) вариантов (3.04проф, 7.12стандарт) системы.
3. Да, с точки зрения процесса - это экстремальное программирование. Вернее сказать, экстремальное конструирование, экстремальное проектирование, экстремальное программирование, экстремальная разработка документации и представительских материалов, экстремальное внедрение и экстремальное сопровождение.
4. Вообще-то говоря, вопросы платформ и оборудования пока в голове не уместились. Есть только мысли о том, что сама система должна быть довольно легкой и многоплатформенной, и позволяющая создавать исполнимый код объектов как с разных языков программирования и систем разработки, так и для разных аппаратных платформ. Например, одна и та же подсистема, на верхнем уровне анализа и конструированная описанная один раз, может иметь несколько вариантов (редакций) реализации для Windows, для Palm OS и т.п.
А вопрос великолепный. Потому что как-то эти редакции нужно объединять еще на уровне проектирования. Значит, система управления вариантами должна быть сложнее той, что я пока вижу.

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

БТР, ударим велопробегом ... :)