Дипломная работа: Автоматизация подсистемы учета статистических данных и формирования
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
54
Внедрение — самый ответственный момент проекта замены информационной
системы. Есть несколько способов начала использования новой системы:
• Параллельная стратегия — для случая, когда старую работающую систему
необходимо заменить новой;
• Скачок — когда прежняя система работала еще в пятницу, а в понедельник
начала работать новая система;
• Опытная эксплуатация пилотного проекта — это стратегия скачка, но
применяется к небольшому числу процессов;
• Узкое место — это наиболее критичная малая часть производственного
процесса. При внедрении узкого места план внедрения выполняется только для
узкого места и для людей, работающих в нем;
Хотя стратегия опытной эксплуатации наиболее надежен и снижает риск, старая
система чересчур неэеффективна. В хучшем случае, в нашей конкретной задаче
мы всегда сможем вернуться к старой системе, соответственно стратегия
параллельного внедрения подходит нам как нельзя лучше.
Создание ИС стартует с выражения цели проекта. ИС обязана
поддерживать требуемую функциональность системы и уровень адаптации к
корректирующим требованиям ее работы; достаточную пропускную способность;
минимальные задержки реакции на запрос; полноценную работу; круглосуточную
готовность (24/7) и доступность системы для анализа запросов от пользователей;
удобство поддержки и использования; должный уровень ИБ.
Исходя из исследований, создание ИС включает изучение 3 областей:
• Подготовку объектов данных, которые будут внедрены в БД;
• Подготовку программ, экранных графиков, форм, отвечающих за
запросы к данным;
• Изучение имеющейся технологичной среды, к примеру: топологии
сети, настройки используемого оборудования, применяемой архитектуры
(файловой или клиент-ориентированной), последовательной или параллельной
обработки данных.
55
В реальных построение системы — это нахождение варианта,
устраивающего требованиям рабочей среды системы посредством доступных
технологий исходя из заданных ограничений.
Создание ИС включает описание всей систем не нескольких уровнях.
Уровень концепции состоит из основных элементов, связей и дополнительных
систем. Уровень логического описания создает модели, включающие структуру
отдельных дополнительных систем и функционирующие связи между ними. На
уровне физического взаимодействия проходит реализация структуры в рамках
программного и аппаратного компонента.
Исходя из цели ИС системы выделяет круг функций, которые нужно этой
системе реализовать. И по факту данного списка функций ИС готовится
конкретная структура, которая именуется как формальная. Подобный тип
структуры включает совокупность активных элементов и отношений между ними,
требуемых и необходимых для реализации указанной цели для системы.
Подобная структура идеальна, т.к. не имеет физической формы восприятия. Она
создается различными средствами, поэтому ей может состоять в совокупности
дополнений. Внешняя среда, работая с ИС, выступает в роли доп. системы, ставя
перед ней конкретные задачи и определяя цели.
Методология реализации прикладных АИС заключается в: процессе
реализации, включающем конкретный набор этапов; вариантов реализации
этапов; средств отображения исходной и итоговой информации всех этапов.
Выполнение анализа классического процесса решения предметных задач на
этапе изначального обследования компании помогает отразить элементы ее
основополагающей деятельности, а именно: определить структуру задач
компании; отразить наиболее значимые задачи, требующие автоматизации;
показать их место обшей структуре задач; разделить (декомпозировать)
конкретную область задачи на отдельные элементы и упорядочить данные для
выбранной задачи в совокупности из каждой составляющей подзадачи.
Начальными данными для реализации данного этапа выступает информация,
принимаемая от специалистов предметной области и рукописных источников
изучаемой компании. Нюансом процесса деления задачи становится применение
56
совокупных принципов и правил разделения, базирующихся на использовании
типичных и классических алгоритмом.
Концепция предметных задач помогает создать систему знаний выбранной
предметной области и захватить ее в требуемой форме. Суть создания концепции
включает использование процедур, которые связаны с генерацией концепций
исходя из совокупности требуемых предметных задач, изучения и синтеза
моделей. Подготовка отражения концепции предметной задачи поддерживает
нахождение базы для корректировки данных, применяемых при автоматическом
варианте и смысловое единство для обобщённых языковых влияний данной
задачи.
Инфологическое построение задач помогает создать их знаковое
отражение, не зависящее от технических и программных методик реализации
АИС, и зафиксировать его в требуемой форме.
Даталогическое моделирование задач связано с необходимостью прямой
адаптации разно уровневых инфо-моделей задач к доступны возможностям
технических и программных средств и методов реализации вычислительной
среды и процесса вычислений. Суть адаптации инфологических моделей данного
вида задач связано с переводом разно-уровневых структур к моно-уровневым
структурам (БД, столбец, таблица), которые возможны в реальных технических и
программных средах и методиках их планирования, а также в изменении
алгоритма исчисления с учетом корректив по доступу к данным. Еще одним
компонентом даталогической модели становится компонент визуализации,
который показывает изменения данных и действий в форме, которая адекватна
для работы и восприятия конечного пользователя в требуемой программной
среде.
И
т
о
г
о
в
к
а
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
57
Проект создания ИС взаимоотношений с клиентами, как и все остальные
проекты по созданию ПО, включает множество неопределенных моментов,
которые могут повлечь за собой риски срыва реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо значительно
уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Модно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот косвенные
риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений, точно
ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что случится,
если ключевые поставщики в силах будут выполнить свои обязательства и т.п.);
58
2) Технические риски:
• Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.1).
Таблица 2.1
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
Заказ
Неформализуемая задача
(невозможно автоматизировать
те или иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
Источник: https://baza.diplomsite.ru/previewfile/1918