
- •Оглавление
- •Введение.
- •Организация процесса конструирования. Жизненный цикл программных средств.
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Планирование программного проекта. Оценка трудоемкости и стоимости программного проекта. Конкурентоспособность.
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе loc- и fp-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Организация разработки программного проекта.
- •Кризис программирования и способ выхода из него
- •Модель cmm-sei
- •Управление качеством разработки программного продукта с помощью системы стандартов iso 9001
- •Примерная структура процесса и организации, занимающейся разработкой программных продуктов
- •Внедрение программного проекта.
- •Что такое проект внедрения.
- •Определение стратегических целей проекта и тактического плана внедрения
- •Обучение специалистов группы внедрения.
- •Моделирование бизнеса.
- •Обучение конечных пользователей работе с системой.
- •Опытно-промышленная эксплуатация
- •Ввод системы в промышленную эксплуатацию.
- •Ключевые факторы успеха.
- •Эволюция программного обеспечения.
- •5.1. Наследуемые системы
- •Количество сбоев аппа- Характеризуются ли аппаратные средства высоким уровнем ратных средств и по сбоев в работе? Является ли по поддержки причиной аварийных перезагрузок системы?
- •5.2. Модернизация программного обеспечения
- •Прогнозирование сопровождения
- •5.3. Реинжениринг программного обеспечения
- •Преобразование исходного кода программ
- •Анализ систем
- •Создание программных модулей
- •Создание абстракций данных
- •Изменение данных
- •5.4. Управление конфигурациями
- •Планирование управления конфигурацией
- •Определение конфигурационных объектов
- •База данных конфигураций
- •Управление изменениями
- •Управление версиями и выпусками
- •Идентификация версий
- •Управление выходными версиями
- •Сборка системы
- •Case-средства для управления конфигурацией
- •Средства поддержки управления изменениями
- •Средства поддержки управления версиями
- •Средства сборки систем
- •Экономическая эффективность эксплуатации программного проекта.
- •6.1. Особенности экономики производства крупных программных продуктов
- •6.2. Проблемы анализа экономики производства программных продуктов
- •6.3. Проблемы организации экономически эффективного производства программных продуктов
- •6.4. Оценка стоимости разработки программного обеспечения
- •6.4.1. Линейный метод
- •6.4.2. Метод функциональных точек
- •6.4.3. Оценка с использованием эмпирических данных
- •6.5. Методы оценки эффективности по на этапе эксплуатации
- •Список литературы.
Внедрение программного проекта.
Итак, вы приобрели продукт, на основании которого планируется создание интегрированной среды управления предприятием. В большинстве случаев, наверное вы догадываетесь, что внедрение - отнюдь не простой процесс, но, к сожалению, практика показывает, что до фактического "погружения" в проект обычно только специалист достаточно высокой квалификации может четко представить все будущие сложности. Как же быть ?
К тому же на рынке широко обсуждаются различные варианты неудачных внедрений. К сожалению дать сколь-нибудь убедительную статистику по этому вопросу представляется крайне затруднительным, так как нет четкого и однозначно принятого всеми участники рынка определения термина "успешное внедрение". . Более того, например SAP AG предпочитает говорить не об успешных, а о "продуктивных" внедрениях, насколько эти термины совпадают по своей семантике? Трудно сказать совершенно определенно, но очевидно, что замена термина на более нейтральный и допускающий явно более широкое толкование - не случайна. Например, если первоначально предполагалось построить на базе одного продукта автоматизацию всех служб производственного предприятия. Но в процессе работы была реализована только функциональность логистики и бухгалтерии, а производственные модули были реализованы на базе другого продукта. Является ли такое внедрение успешным? Но продуктивным - безусловно. Также если продукт был приобретен и даже оплачен, а внедрение фактически не начато - можно ли вообще такую ситуацию считать внедрением, а тем более неудачным.
А российские продукты? Легенда гласит, что они более легки во внедрении ? К сожалению, данный тезис не находит подтверждения на практике. При использовании одних и тех же критериев успешного внедрения и при одинаковой функциональности, показатели внедрения примерно одинаковы. Для продуктов, предназначенных для автоматизации крупных компании процент успеха можно оценить в 60 успешных внедрений на 100 продаж, для продуктов автоматизации более мелких компаний - не менее 80. Эти данные косвенно подтверждаются данными по западному ERP рынку Гартнер Групп, которая более осторожно изучает процент соответствия проектов внедрения плановым показателям и оценивает этот показатель для ERP систем также около 60 % (из них процент "досрочных" внедрений около 3%), а вот процент полностью провалившихся проектов в 10 %. Но нужно иметь в виду, что здесь рассматриваются только запущенные проекты, а в России есть значительный процент вообще не начавшихся проектов, а также проектов, замороженных на промежуточных стадиях на неопределенный срок по форс-мажорным обстоятельствам, как например смена собственника или августовский кризис.. Непонятно к какой категории относить такие проекты.
Что касается сложностей внедрения иностранных программных пакетов, то, как известно, не бывает дыма без огня. С точки зрения психологического воздействия, внедрение западных продуктов как правило требует больших усилий, за счет другой организации финансового учета, непривычных интерфейсов, не всегда ясной терминологии, как правило из-за недостатков перевода. Опять же нужно различать внедрение тиражируемого продукта, то есть достаточно функционально жестко организованного, и внедрение с доработкой, когда производится существенная программная разработка функциональности и интерфейсов под требования покупателя. Во втором случае, характерном для российских продуктов, критерии успешности внедрения еще более размыты. Теоретически такого рода внедрения должны реализовывать всё желательные функциональные блоки, что на практике не имеет места. К тому же количество инсталляций продуктов многих российских продуктов обычно исчисляется десятками, а такую выборку трудно считать представительной, так как при таком количестве продаж велики зависимые факторы (с этой точки зрения и большинство западных продукты в России не имеют представительной выборки, но там можно воспользоваться западным опытом).
Что же делать? Как обуздать процесс внедрения, который представляется необъезженным мустангом, кажется способным вырваться из любых пут?
Но и на буйную стихию есть управа - желание и труд, помноженные на опыт и вековые правила. Так и процесс внедрения может стать в целом вполне предсказуем и управляем, если следовать принципам, изложенным далее в этой статье.