×
Показано с 1 по 10 из 10
  1. БТР
    Гость

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


    <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
    Поделиться с друзьями

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

  3. Клерк Аватар для training1C
    Регистрация
    16.09.2002
    Адрес
    Москва, СВАО
    Сообщений
    861
    "тихо, сам с собою я веду беседу" :-)
    С уважением, Рустам.
    "Пишите письма мелким почерком" :-). Ответ ГАРАНТИРОВАН

  4. Фырчун Аватар для Dracosha Andrew
    Регистрация
    07.02.2002
    Адрес
    Санкт-Петербург
    Сообщений
    2,259
    БТР
    Я бы попросил воздержаться от столь объемных постингов.

    Удалил, потому как читать невозвожно.
    training1C Абсолютно прав.
    Всех благ!!!
    Чувелёв Андрей

    ps: Всё вышеизложенное является моим частным мнением и не может претендовать на полноту изложения.

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

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

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

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

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

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

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

  7. Клерк
    Регистрация
    22.01.2003
    Сообщений
    1
    БТР, анонимное выссказывание принадлежит мне.

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

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

  10. Писарь
    Регистрация
    05.03.2002
    Адрес
    Москва
    Сообщений
    3,979
    БТР, ударим велопробегом ...

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)