Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Diplom_itogovii.docx
Скачиваний:
5
Добавлен:
01.05.2025
Размер:
3.67 Mб
Скачать

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

При осуществлении проекта часто случаются ситуации, когда возникает неполнота, неточность или неопределенность в информации об условиях, сроках, затратах и результатах проекта. Все лица, участвующие в проекте заинтересованы в том, чтобы проект не провалился. Для этого, чтобы избежать каких-либо просчетов и лишних затрат, следует проанализировать всевозможные риски на каждом из этапов жизненной цикла ИС.

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

Этап заказа информационной системы.

На данном этапе возникает два возможных риска – это повышение цены на систему, либо отсутствия этой системы у продавца. Чтобы снизить величину такого риска следует провести анализ потребительского рынка и цен на необходимый товар с учетом инфляции. После проведения анализа следует немедленно заказать систему у фирмы – производителя.

Этап процесса поставки

На данном этапе может возникнуть риск того, что товар не будет поставлен в оговоренные сроки. Для избегания этого риска следует пользоваться услугами проверенных поставщиков, либо сразу оговаривать сроки поставки.

Этап процесса разработки.

Здесь нередко возникает риск недопонимания со стороны фирмы производителя о том, какие требования должны предъявляться к разрабатываемой системе. Чтобы избежать эти недопонимания, следует сразу четко формировать требования к приобретаемой системе.

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

Риск данного этапа состоит в том, что может возникнуть неисправность, как в самой системе, так и в оборудовании, которое используется для работы системы. Чтобы предотвратить этот риск, следует использовать оборудование «с запасом прочности» для проведения тестирования внедряемой системы.

Этап сопровождения системы.

Нередко в момент эксплуатации системы она выходит из строя. Это может обуславливаться несколькими причинами: либо становится неисправным оборудование, на котором работает система, либо возникает внутренняя ошибка программного обеспечение, либо к этому приводит неловкое действие и ошибка персонала. Для предупреждения данной ситуации необходимо делать резервные копии системы и ее базы данных на серверах и проводить каждодневную синхронизацию.

Этап обучение персонала.

Зачастую у пользователей в ходе работы с новой системой возникают сложные ситуации, когда они не знают, что им делать. Чтобы избежать этой ситуации, необходимо создать точные методические указания по работе с ИС, либо ввести человека-куратора, который может объяснять непонятные моменты в ходе работы on-line.

2.4 Информационная модель объекта проектирования

Информационная модель — модель объекта, представленная в виде информации, описывающей параметры и переменные величины объекта, связи между ними, входы и выходы объекта и позволяющая путём подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта [9].

Рассмотрим информационную модель процессов «управление обращениями пользователей» на рисунке 2.4.

На данной схеме наглядно показано как происходит процесс обработки заявки. Когда сотрудник обращается в службу поддержки, представитель службы поддержки создает запись об инциденте при помощи приложения Service Desk. Инженер первой линии записывает имя пользователя, имя компонента, по поводу которого обращается сотрудник, и описание запроса на услугу. После сбора информации начинаются действия, необходимые для разрешения запроса пользователя:

  • Если запрос на услугу разрешен без его эскалации до уровня инцидента, инженер может закрыть запись об обращении;

  • Если запрос на услугу нельзя разрешить без его эскалации до инцидента, представитель службы поддержки выполняет поиск существующих инцидентов, которые затрагивают тот же компонент или один из родительских активов этого компонента.

  1. если существующий инцидент найден, представитель службы поддержки может связать текущее обращение с записью о существующем инциденте;

  2. если запись о существующем инциденте не найдена, инженер первой линии поддержки может зарегистрировать новый инцидент на основании обращения в службу поддержки. Service Desk копирует информацию из записи об обращении в только что созданную запись об инциденте.

Рисунок 2.4 – Информационная модель процессов «управление обращениями пользователей»

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]