61
• Формируются требования пользователя;
• Обосновывается необходимость разработки.
В данном этапе задействованы следующие участники: IT-менеджер, начальник
отдела производства. После реализации всех задач составляет ся отчет о проделанной
работе - описание объекта автоматизации, требований к системе, выражение затрат
на создание, введение в эксплуатацию и поддержку, ожидаемый эффект от внедрения
и требуемые условия для нормальной работы системы.
После выполнения этапа «Выведение требований к системе» создается вариант
концепции. Разрабатывают несколько вариантов концепции и плана реализации,
оценивают ресурсы, необходимые на реализацию ИС и ее нормальную работу,
оценивают недостатки и достоинства каждого метода, сопоставляют требования
пользователей и функциональности возможной системы.
На этапе «Создание концепции» участвует только IT-менеджер. После того, как
работа выполнена, выбирается наиболее удачный из всех подходящих вариантов,
который полностью удовлетворяет всем требованиям.
После этапа «Создание концепции» составляется ТЗ проекта автоматизации. По
его завершению важно его утвердить и согласовать. На данном этапе участвуют: IT-
менеджер и начальник отдела делопроизводства. По итогам данный пункт может
определять - функции ИС и подсистем, состав отдельных и комплексных задач,
концепцию информационной базы, состав системы управления БД, функции и
параметры программных средств.
После утверждения ТЗ идет разработка проектного решения. 1Тменеджер и
программист разрабатывают логическую и физическую модель БД, а также
определяют общую организацию данных.
После завершения этапа «Составление технического проекта» IT-менеджер и
программист оформляют рабочую документацию, которая включает: технические и
программные требования, руководство пользователя. После завершения всех работ и
написания документации остаётся только внедрить систему.
Этап внедрения включает в себя: подготовку объекта автоматизации, обучение
сотрудников, проведение строительно-монтажных работ, пусконаладочных работ,
проведение испытаний, опытная эксплуатация и приемочные испытания. В этом этапе
62
участвуют: IT-менеджер, системный администратор, начальник делопроизводства.
После этого происходит анализ испытаний ИС, проверка на соответствие ТЗ,
устраняются неполадки или подписываются все акты.
Особое внимание всегда уделяется начальным этапам разработки -
проектированию и анализу, где все технические решения проверяются и
обосновываются посредством представления прототипов.
Стандартная каскадная модель, несмотря на последние негативные отзывы,
исправно помогала специалистам по программному инжинирингу много лет.
Понимание ее сильных и слабых сторон только улучшает оценочный анализ других,
чаще более эффективных моделей ЖЦ, которые также основаны на данной модели.
Сама каскадная модель имеет множество преимуществ, но при условии
использования ее в проекте, приемлемом для нее. Ниже представлены ее
преимущества:
• Модель хорошо знакома потребителям, не имевшим никакого отношения
к созданию и эксплуатации программ, а также конечным пользователям (часто
используется другими компаниями для отслеживания проектов, которые не связана с
разработкой ПО);
• Она лучше справляется с трудностями и отлично срабатывает в тех
проектах, где все достаточно понятно, но трудноразрешимо;
• Она очень доступна для понимания, т.к. преследует простую цель -
выполнение необходимых действий;
• Она проста и удобно в использовании, т.к. процесс разработки идет
поэтапно.
Но в случае, если каскадная модель используется в проекте, не
предназначенном для нее, проявляются следующие ее недостатки:
• Основа модели - линейная последовательная структура, и в результате
попытки вернуться назад на одну-две фазы для исправления проблемы или
недостатка приходится жертвовать временем и срывать график работ и затрат;
• Она не может предотвращать итерация между фазами, которые очень
часто встречаются при создании ПО, поскольку сама модель строиться согласно
циклам аппаратного инжиниринга;
63
• Она не показывает главное свойство разработки ПО, которое направлено
на решение задачи. Отдельные фазы связаны определенными действиями, что часто
отличается от привычной работы коллектива или персонала;
• Она создает ошибочное впечатление о работе с проектом. Указание, что
«35% выполнено» обычно не имеет какого-то смысла для менеджера проектов.
Исходя из недостатков каскадной модели, ее применение нудно ограничивать
ситуациями, в которых все требования для их разработки очень точны и понятны.
Каскадная модель хороша в циклах разработки программного продукта, где
используется фиксированное определение продукта и есть понятные технические
методики.
Спиральная модель особое внимание уделяет начальным этапам разработки -
подготовке стратегии, проектированию и анализу, где все применяемые технические
решения проверяются и обосновываются методом создания прототипов. Каждый
виток спирали означает создание компонента или версии ПО. В них можно уточнять
цели и характеристики проекта, его качество, а также выражаются работы на
следующем витке. Таким образом, углубляются и конкретизируются детали проекта,
и в результате определяется обоснованный вариант, который и реализуется.
Спиральная модель показывает в себе преимущества каскадной модели. При
этом она также имеет риски, умеет или управлять, а также имеет процессы поддержки
и менеджмента. Тут также имеется разработка ПО при использовании
прототипирования или быстрой разработки программ при помощи языков
программирования и средств разработки 4-го поколения.
Особые свойства спиральной модели - отказ от закрепления требований и
установки приоритетов пользовательским требованиям; создание последовательных
прототипов, начиная с наиболее высшего; определение и анализ риска на каждом
шаге; оценка результата по итогам каждой итерации и планирование проведения
следующей итерации.
Преимуществами спиральной модели можно назвать:
• Быстрая разработка (получение более раннего результата за счет
прототипа);
• Постоянное присутствие зхаказчика с процессе разработки;
64
• Разбиение большого проекта на малые части;
• Снижение рисков (более предсказуемое поведение системы).
Для нашего проекта больше всего подойдет каскадная модель для создания
приложения, т.к. она имеет возможность контроля промежуточных значений, а также
проект не слишком большой, что может повлиять на отсутствие ее недостатков.
Затем производится выбор направления внедрения созданной системы. Сегодня
выделяют 4 стратегии внедрения ИС:
• Параллельная стратегия, которая подразумевает замену старой на новую;
• Скачок - подразумевается резкий переход с одной системы сразу на
другую;
• Опытное использование пилотного проекта - та же тактика скачка,
только к некоторому количеству изделий, при этом очень успешна на малом участке
работы;
• Узкое место - внедрение узкого места план выполняется только для него
самого, и для сотрудников, которые там работают.
В итоге исходя из описаний и условий деятельности фирмы, а также из
характеристик создаваемой системы, в качестве стратегии выбирается «опытное
использование пилотного проекта», что позволяет установить всю систему сразу же
после ее подготовки. При этом прекращается использование ручного учета данных,
что позволяет значительно увеличивать скорость работы сотрудников фирмы прямо с
первого дня использования системы, и в таком случае само внедрение пройдет
безболезненно.
Для разработки системы управленческого учета будем использовать стандарт
ISO 12207-99, как наиболее подходящий для данного случая.
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
65
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа - основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит выбор
поставщика / разработчика и непосредственно управление заказом вплоть до приемки
готовой системы.
Процесс поставки - исполнитель организация поставщик. Этап начинается с
подписания договора на поставку системы, продолжается определением процедур и
ресурсов, необходимых для обеспечения выполнения проекта. И заканчивается
поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс включает в
себя работы по анализу требований, проектированию, программированию, сборке,
тестированию и вводу в действия программного продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала, ответственного
за сопровождение программного продукта. Этот процесс реализуется при
модификациях программного продукта и документации к нему, вызванных
изменениями в связи с улучшением или устранением ошибок. Целью процесса
является изменение существующего программного продукта при сохранении его
целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
66
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
67
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
Для рассматриваемого в данном дипломном проекте наиболее подходит
спиральная модель жизненного цикла информационной системы, так как:
• Разработка имеет небольшой объем;
• Требования к системе формализованы;
• Изменения функциональности не планируются.
В качестве стратегии внедрения ИС был выбран «Пилотный проект».
Пилотный проект - это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до ее окончательного
внедрения, обучить сотрудников компании работе с системой, а также определить и
спланировать организационные и технические мероприятия на этапе промышленного
внедрения. Пилотный проект позволяет уменьшить затраты и ускорить
полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана, потому
что это наиболее часто используемая компаниями стратегия. Такой подход снижает
риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Любой сложный проект, а особенно проект разработки программного
обеспечения, содержит в себе много неопределенных моментов, которые влекут за
собой риски реализации проекта.
Управление рисками заключается в их раннем выявлении и разработке мер
либо полностью предотвращающих их возникновение, либо минимизирующих их
последствия.
В настоящее время существует три общепринятых стратегии управления
рисками:
68
• Избегание рисков - проект реорганизуется таким образом, чтобы
исключить возможность возникновения рисков;
• Делегирование рисков - проект реорганизуется таким образом, чтобы
переложить риски на третью сторону (заказчика, банки, вендора и т.п.);
• Принятие рисков - риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае наступления рисков.
Различают две основные категории рисков - прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а
опосредованные риски команда контролировать не может в принципе.
Риски делятся на следующие основные виды:
• Ресурсные риски:
о Организация (выполняла ли организация прежде проекты такого
масштаба, существует ли формальный процесс разработки программного
обеспечения и т.п.);
о Финансирование (полностью ли обеспечено финансирование проекта,
фиксирована ли стоимость проекта или она является предметом для обсуждения,
точно ли выполнена оценка затрат и т.п.);
о Люди (достаточно ли людей для выполнения проекта, обладают ли они
необходимыми навыками и опытом, работали ли они вместе раньше и т.п.);
о Время (реалистичен ли план проекта, насколько критичной является дата
окончания проекта и т.п.);
о Бизнес (что произойдет, если конкурент выйдет на рынок первым,
выгода, полученная от реализации проекта больше, чем затраты на него, что
произойдет, если ключевые поставщики не смогут выполнить свои обязательства и
т.п.);
• Технические риски:
о Область действия (scope) проекта (могут ли быть измерены критерии
успешного завершения проекта, требования стабильны и хорошо поняты, область
действия жестко фиксирована или может расширяться в будущем и т.п.);
69
о Технологии (отлажена ли применяемая технология или она только была
разработана, и т.п.);
о Внешние зависимости (зависит ли проект от других параллельных
проектов, зависит ли успех проекта от внешних поставщиков технологий и/или
продуктов и т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.1).
Таблица 2.1
Основные риски на этапах жизненного цикла информационной системы
Этап Риск Мероприятия
Заказ Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
Заказ
Неформализуемая задача
(невозможно автоматизировать
те или иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
Проектирование - неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов решения
поставленных задач;
- несоблюдение требований
заказчика при проектирование
будущей системы или
постоянное изменение
требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
70
Недостаточно опыта у
персонала заказчика, который
будет эксплуатировать систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение - увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС
Кроме того, в процессе эксплуатации и сопровождения разработанной ИС
могут возникнуть:
• технические риски;
• риски персонала.
Факторами технических рисков являются:
• ошибки в программе вызывающие простой системы;
• невозможность осуществления требуемых действия,
«зависание»программы;
• использование вредоносных программ (вирусы, черви, трояны,
логические бомбы), использование в корыстных целях найденных ошибок (дыр) в
программах,
• перехват информации по телекоммуникациям, воровство информации;
• некорректная эксплуатация оборудования;
• приостановка деятельности третьего лица (например, провайдера
Интернет услуг), что повлечет за собой невозможность передачи отчетов из филиалов
и контроля деятельности филиалов;
• несоответствие функциональных возможностей системы бизнес -
процессам в комплекса задач в следствие реорганизационных изменений.
Предотвратить данные обстоятельства можно, соблюдая следующие моменты:
• тщательное тестирование и выявление ошибок на этапе разработки;