Материал: Автоматизация контроля расчетов с абонентами в ЗАО "ХАНТСМАН-НМГ"

Скачать файл

Заказать новую работу

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

• Поддержка пользователей

• Проведение обучающих лекция для пользователей

• Подготовка отчетов о работе системы

Сопровождение

• Анализ ошибок и их устранение

• Подготовка отчетов по модификациям и изменениям

• Обновление функционирующих систем

На первоначальном этапе после проведения анализа деятельности

организации, необходимо поставить цели и задачи автоматизации и разработать

план проекта. После документального оформления начинается непосредственно

сам процесс разработки. Создается база данных, отчетные формы, пишется

программный код по сбору, обработке и хранению информации, создаются

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

По завершению тестирования готовится план эксплуатации и документация для

внедрения, а так же различная пользовательская документация. Процесс будет

происходить следующим образом. Так как в организации уже существует ЛВС и

стабильно функционирует, в ее наладке нет необходимости. Первоначально

устанавливается серверная часть системы учета продаж, далее на рабочие места

проходит установка и настройка клиентских приложений системы учета продаж и

СУБД. Тестируется работоспособность, проводится демонстрация работы

системы для руководства и персонала. Последней стадией будет проведение

семинаров для сотрудников компании. Необходимо связать всех сотрудников,

отвечающих за обработку документов в единую информационную сеть. Для этого

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

определенным отделам

За эксплуатацию готовой системы, будет отвечать оператор. В его задачу

будет входить:

1. Разработка плана эксплуатации и определения набора стандартов

эксплуатации.

2. Получение и документирование сведений о возникающих проблемах, их

решение и контроль за возникновением, обеспечение обратной связи с

пользователями.

3. Тестирование системе в эксплуатационной среде, кооперация со службой

сопровождения для устранения возникших проблем и модернизации системы.

4. Поддержка и консультация пользователей.

Жизненный цикл (ЖЦ) ИС представляется, как ряд событий, случающихся

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

Модель ЖЦ отражает различные состояния системы, от момента

возникновения необходимости в данной ИС и до момента ее окончательного

вывода из эксплуатации. Модель жизненного цикла представлена некой

структурой, которая содержит процессы, действия и задачи, реализуемые в ходе

создания, работы и сопровождения ПО в течение всей жизни системы, от

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

Сегодня известны и применимы следующие модели жизненного цикла:

• Каскадная модель включает в себя последовательную реализацию

всех этапов проекта в заранее определенном порядке. Начало следующего этапа

говорит о полном завершении работ на предыдущем этапе.

• Поэтапная модель с периодичным контролем. Создание ИС

реализовано в виде итераций с циклами обратной связи между этапами.

Межэтапные проверки позволяют учесть реально существующее взаимовлияние

итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на

весь срок разработки.

• Спиральная модель. На любом витке спирали выполняется генерация

очередной версии продукта, корректируются требования проекта, выражается его

качество и планируются работы уже следующего витка. Особое внимание при

этом обращается на начальные этапы разработки - анализ и проектирование, где

возможность создания тех или иных технических решений обосновывается и

проверяется благодаря построению прототипов.

Каскадный подход отлично зарекомендовал себя в процессе создания

относительно простых ИС, когда в самом начале разработки можно с большой

точностью и полнотой составить все требования к системе. Главным недостатком

такого подхода является то, что основной процесс разработки системы не может

полностью уложится в такие жесткие рамки, постоянно есть потребность в

возврате к уже завершенным этапам для уточнения или изменения ранее принятых

решений. В итоге реальный процесс разработки ИС становится соответствующим

поэтапной модели с периодичным контролем.

На настоящий момент существуют такие модели жизненного цикла, как

каскадная, поэтапная с промежуточным контролем, спиральная.

В спиральной модели особое внимание уделяется начальным этапам

разработки – выработке стратегии, анализу и проектированию, где реализуемость

тех или иных технических решений проверяется и обосновывается посредством

создания прототипов (макетирования). Каждый виток спирали предполагает

создание фрагмента (компонента) или версии программного продукта. На них

уточняются цели и характеристики проекта, определяется его качество и

планируются работы следующего витка спирали. Таким образом углубляются и

последовательно конкретизируются детали проекта и в результате выбирается

обоснованный вариант, который доводится до реализации.

Для разрабатываемого проекта наиболее подойдет каскадная модель для

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

Существует 4 основных способа начала использования новой системы

 Параллельная стратегия;

 Скачок;

 Узкое место;

 Опытная эксплуатация "пилотного проекта.

Параллельная стратегия не подходит , так как компания не располагает

достаточными ресурсами для ведения учета одновременно в автоматизированном

и ручном вариантах. Стратегия Скачек не позволяет плавно перейти на

использование разработки, узкое место больше подходит для использования в

крупных компаниях. Поэтому в качестве стратегии внедрения ИС была выбрана

«Опытная эксплуатация пилотного проекта».

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

На каждом этапе жизненного цикла ИС есть различные риски. Они

приводят как к серьезным неустойкам во в процессе разработки системы, так и в

ее функциональных возможностях.

Далее будут представлены риски в зависимости от процессов ЖЦ, а также

возможные методы их предотвращения.

Процесс подготовки проекта

Риск персонала

Риски:

• Набор необученного персонала к выполнению проекта;

• Набор в группу разработчиков «случайных» сотрудников, а не

главных участников автоматизируемых процессов производства;

• Неимение выработанной стратегии автоматизации;

• Несогласованность в общих целях и задачах проекта;

• Отсутствие мотивационных поощрений сотрудникам;

• Нежелание персонала участвовать в проекте;

• Хаотичный план ведения работ.

Методики предотвращения:

• Постоянное взаимодействие с руководством в процессе всего

проекта, оперативное принятие решений;

• Привлечение к проекту ведущих специалистов и консультантов;

• Четкая формулировка целей и задач;

• Выработка определённой стратегии автоматизации компании;

• Неизменный состав рабочей группы во время подготовки проекта.

Риск ведения проекта

Риски:

• Ошибочная установка границ и масштаба проекта;

• Выделение ошибочных функций системы;

• Подбор неверных технологий и методологий решений задач;

• Несоблюдение приведенных заказчиком требований.

Методики предотвращения:

• Поддержка стабильности границ проекта, которые выделяются еще

на начальном этапе и неизменны вплоть до финала проекта;

• Точное планирование выполняемых работ;

• Включение в проект необходимых ресурсов;

• Согласованное и утвержденное проектное решение;

• Высокий порог принятия изменений.

Риск неверного планирования

Риски:

• Малоэффективный план организации разработки системы;

• Несоблюдение сроков реализации работ по этапам.

Методики предотвращения:

• В начальных стадиях проекта проведение учета, организация

командной работы, выделение ролей и стимулирование;

• Описание и сохранение всех проведенных работ и открытый доступ

к этим данным для всех участников проекта.

Процесс разработки

Риск персонала

Риски:

• Увольнение сотрудников, которые отвечают за проведение

разработки;

• Несогласованность действий между участниками проекта из-за

плохой системы коммуникации;

• Ошибочное представление задачи проектирования;

• Набор разработчиком без опыта работы с подобными системами.

Методики предотвращения:

• Грамотный набор сотрудников, участвующих в проекте;

• Реализация четкой системы взаимодействия между сотрудниками,

полное документирование изменений в системе.

Технические риски

Риски:

• Остановка разработки из-за ошибок в применяемом ПО;

• Пользовательская документация состоит из описания лишь

некоторых функций системы.

Методики предотвращения:

• Работа только с проверенным лицензионным ПО, регулярное

резервное копирование данных;

• Отслеживание полноты сведений во всех документах.

Источник: https://baza.diplomsite.ru/previewfile/1837

Смотрите также:










2014 biblioonline ru