системы. В этой модели главное значение придается действиям, направленным
на подтверждение и проверку продукта. Она отражает, что проверка продукта
обсуждается, конкретизируется и планируется еще на ранних стадиях ЖЦ
разработки. План приемки продукта заказчиком пишется на этапе планирования,
а само испытание системы - на фазах разработки и анализа проекта и т.д. Такой
процесс создания планов испытания выделен пунктирной линией между
прямоугольниками V-образной модели
В процессе применения V-образной модели при создании проекта, для
которого она оптимально подходит, реализуется несколько преимуществ:
• Модель придает особое значение придается планированию,
направленному на подтверждения и проверки создаваемого ПО еще на
начальных стадиях его разработки. Этап модульного тестирования подтверждает
правильность детализированного проектирования. Этапы внедрения и проверки
описывают архитектурное проектирование или проектирование на высоком
уровне. Этап проверки системы подтверждает правильность выполнения этапа
требований к продукту и его параметров;
• Модель предусматривает аттестацию и подтверждение всех
внешних и внутренних полученных данных, а не только исходного ПО;
• V-образной модель выполняет определение требований перед
началом разработки проекта системы, а само проектирование ПО проходит
перед созданием компонентов;
• Модель определяет продукты, полученные в результате процесса
разработки, и все полученные данные подвергаются тестированию;
В процессе применения V-образной модели в работе над проектом, для
которого она не совсем подходит и недостаточно приемлема, проявляются ее
недостатки:
• Этой модели непросто справиться с параллельными событиями;
• В ней не учитываются итерации между фазами;
• В ней нет внесенных требований динамических изменений на
разных этапах ЖЦ;
• Проверка требований в ЖЦ реализуется слишком поздно, поэтому
невозможно внести корректировки, не повлияв при этом на сроки выполнения
проекта;
• Модель не включает действия, направленные на анализ рисков.
Как и каскадная модель, V-образная модель также лучше срабатывает
тогда, когда вся информация о требованиях заранее известна.
Общераспространенная модификация V-образной модели, направленная на
преодоление ее недостатков, включает в себя внесение итерационных циклов
для разрешения изменения в требованиях за рамками фазы анализа.
Применение модели эффективно тогда, когда доступными являются
данные о методе разработки решения и технология, а персонал обладает всеми
умениями и опытом в работе с используемой технологией.
Отличительной чертой RAD становится короткое время перехода от
выявления требований до разработки полной системы. Метод базируется на
совокупности итераций эволюционной системы или прототипов, критический
анализ которых утверждается у заказчика. Во время такого анализа
составляются требования к продукту.
Создание каждого внедренного продукта ограничивается четко
выделенным периодом времени, который обычно составляет 60 дней и носит
название «временной блок».
Инкрементная разработка включает в себя процесс частичного создания
всей системы и неторопливого наращивания функциональных возможностей.
Подобный подход дает возможность минимизировать затраты, понесенные до
момента достижения уровня установленной производительности. При помощи
такой модели убыстряется процесс разработки действующей системы. Этому
способствует используемый принцип сочетания из стандартных блоков, который
позволяет обеспечить контроль над процессом внедрения указанных требований.
Спиральная модель включает в себя положительные стороны каскадной
модели. При этом она также включает анализ рисков, может управлять ими, а
также имеет процессы поддержки и менеджмента. В ней также предусмотрено
создание программного продукта при помощи метода прототипирования или
быстрой разработки приложений с применением языков программирования и
средств разработки 4 поколения и выше.
На основании описания моделей разработки выбираем спиральную
модель.
Среди самых популярных стандартов ЖЦ часто выделяют такие:
• ГОСТ 34.601-90 – используется в АИС и устанавливает все этапы и
стадии их создания. Также он описывает содержание работ для любого этапа.
Стадии и этапы, закрепленные внутри стандарта, больше всего соответствуют
каскадной модели ЖЦ;
• ISO/IEC 12207 – стандарт, указывающий процессы и организацию
ЖЦ. Может использоваться в любом виде заказного ПО. Стандарт не имеет
описания стадий и этапов;
• Custom Development Metho – технологический материал по
созданию прикладных ИС, детализированный до уровня заготовок проектных
решений, которыми пользуются в проектах с использованием средств Oracle.
Применяется CDM для классической модели ЖЦ (есть все этапы и описанные
задачи), а также в процессе «оперативной разработки» или «облегченного
прохода», которые применяются в рамках малых проектов;
• Rational Unified Process (RUP) – применяет интерактивную модель
разработки, включающую 4 фазы: старт, изучение, создание и внедрение.
Каждая из фаз может делится на этапы, которые в итоге создают версию для
внутреннего или внешнего применения. Завершение всех 4 фаз – это цикл
разработки, и по завершению одного цикла генерируется новая версия системы.
Если по факту проект продолжается, то сам продукт тоже изменяется и проходит
вновь эти 4 фазы. Суть работы при использовании RUP – создание и поддержка
моделей на базе UML;
• Microsoft Solution Framework (MSF) – аналогичен RUP, тоже
состоит из 4 фаз: изучение, разработка, реализация и проверка, считается
итерационным и включает применение объектно-ориентированных моделей.
MSF в отличии от RUP чаще всего используется для создания бизнес ПО;
• Extreme Programming (XP) – экстремальное программирование
(современная методология, создана в 1996 году). Ее суть составляют командная
работа, постоянная коммуникация с заказчиком в рамках всего проектирования
ИС, создание проекта с использованием последовательно оптимизируемых
прототипов.
Опираясь на это список, определим некоторые модели ЖЦ АИС —
итерационную, спиральную и каскадную.
Последняя модель включает стандартный подход к реализации ИС в
различных предметных областях и включает поочередную реализацию работ, но
главным аспектом модели считается разделение процесса создания на этапы
[16].
Для внедрения решения по проекту важно изначально определить базовые
этапы ЖЦ создаваемой системы. Из всех присутствующих стандартов, самым
подходящим станет ISO 12207 -99 [2]. Выбираем именно эго из-за ряда
факторов: сам стандарт на 100% не регламентирует очередность процессов
каждого этапа, что помогает реализовывать самые удобные для нас процессы.
Также стандарт включает все этапы на полноценной основе, в сравнении с
остальными стандартами. И еще, стандарт 12207-99 не отражает этапы, он лишь
регламентирует их, что помогает создателю лично контролировать ЖЦ.
Стандарт ISO 12207 имеет 16 процессов, разделенных на 3 группы.
Процессы включают виды деятельности. Всего в стандарте определено 74
вида деятельности, которые связаны с созданием и поддержкой ПО. Любой
такой вид нацелен на реализацию конкретной задачи или их совокупности.
Базовый процесс ЖЦ включает 5 этапов:
• Оформление заказа;
• Получение;
• Создание;
• Использование;
• Управление.
Любой процесс имеет своего главного исполнителя и действия, требуемые
к выполнению в назначенные сроки. Процесс заказа: главный исполнитель -
заказчик ИС. Тут отражается потребность заказчика в ИС, определяется
поставщик или создатель, происходит управление заказом вплоть до получения
готовой продукции.
Получение – исполнитель: компания-поставщик. Этап включает
составление договора на поставку системы, выделение ресурсов и процедур,
требуемых для исполнения проекта. Завершается этап получением полноценной
системы и составлением актов.
За создание ответственна компания-разработчик. Процесс состоит из
анализа требований, создания проекта, программирования, тестирования и
сборки, а также установки ПО.
Процедура использования отражает работу оператора. Она включает
использование программного продукта и помощь пользователям по факту
работы.
Процесс управления включает деятельность персонала, который отвечает
за поддержку программного продукта. Этот процесс основан на обновлениях
самого ПО и документации к нему, которые необходимы для улучшения и
исправления ошибок. Целью процесса – корректировка имеющегося ПО при
сохранении совокупной целостности.
Исходя их описанного выше стандарта, выделим несколько этапов
разработки АСУ [32]:
Начало проекта:
• Исследование работы;
• Выполнение предварительного анализа;
• Подготовка плана проекта.
Создание:
• Разработка таблиц и связей БД;
• Разработка шаблонов отчетных файлов;
• Внедрение процедур по получению, хранению и анализу
информации;
• Подготовка процедур фильтрации;
• Создание интерфейса пользователя.
Тестирование работы системы:
• Отладка словарей и справочников;
• Проверка работоспособности системы;
• Исправление системы по итогам проверки;
• Написание документации для внедрения;
• Подготовка плана эксплуатации;
• Написание документов по установке и настройке ПО;
• Создание плана внедрения.
Установка:
• Инсталляция на сервер СУБД;
• Инсталляция серверных модулей системы учета продаж;
• Инсталляция клиентских модулей системы учета продаж;
• Отладка серверной и клиентских частей;
• Проверка работы системы;
• Представление работы системы;
• Организация плана по проведению обучения пользователей;
• Планирование семинара по обучению работе с системой;
• Представление системы службе эксплуатации.
Использование:
• Подготовка плана использования;
• Ввод системы в рабочий режим;
• Перевод системы в промышленную эксплуатацию по итогу
тестирования;
• Реализация поддержки пользователей;
• Обучение для пользователей;
• Генерация отчетов по работе системы;
Управление:
• Нахождение и устранение ошибок;
• Генерация отчетов по обновлениям и изменениям;
• Модернизация функционирующих систем.
Изначально после проведения анализа работы компании, важно поставить
цели и задачи автоматизации и подготовить план проекта [33]. После создания
документов начинается сам процесс реализации. Создается БД, отчетные формы,
программируются алгоритмы по сбору, анализу, хранению данных, реализуются
процедуры фильтрации. По факту создания системы, начинается этап
тестирования. По итогам тестирования получается план эксплуатации и
документация для установки, а также дополнительная пользовательская
документация. Процесс происходит так: поскольку в компании есть текущая
ЛВС и работает он нормально, в ее наладке необходимости нет. Изначально
запускается серверная часть системы учета продаж, позже на рабочие места
ставится и настраивается клиентская часть системы учета продаж и СУБД.
Проверяется работоспособность, показывается работа системы персоналу и
руководству. Финальной стадией становится реализация семинаров для
персонала компании. Важно объединить всех сотрудников, которые отвечают за
анализ документов в единую ИС. Для этого клиентские приложения ставятся в
строго оговоренной последовательности по нужным отделам [34].
За поддержку готовой отвечает оператор. В его обязанности будет
включено:
• Подготовка плана эксплуатации и отражения набора стандартов
эксплуатации;
• Документирование сведений по текущим проблемам, их решение и
контроль за работой, обеспечение обратной связи с клиентами;
• Проверка системе в среде работы, взаимодействие со службой
сопровождения для минимизации возникших проблем и обновлений системы;
• Консультирование пользователей.
Исходя из выбранной модели, базовые этапы разработки состоят из:
• Подготовка требований;
• Процесс проектирования;
• Внедрение;
• Проверка;
• Установка;
• Использование и поддержка.
Есть 4 варианта начала применения новой системы:
• Параллельное применение;
• Скачкообразное применение;
• Явление узкого места;
• Использование пробной версии.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация "пилотного проекта.
Параллельная стратегия не подходит, так как компания не располагает
достаточными ресурсами для ведения учета одновременно в
автоматизированном и ручном вариантах. Стратегия Скачек не позволяет плавно
перейти на использование разработки, узкое место больше подходит для
использования в крупных компаниях. Поэтому в качестве стратегии внедрения
ИС была выбрана «Опытная эксплуатация пилотного проекта».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На всех этапах жизненного цикла информационной системы встречаются
различные риски. Они могут приводить как к серьезным неустойкам во времени
разработки системы, так и в ее функциональных качествах.
Ниже представлены риски в зависимости от этапов жизненного цикла, а
также приведены методы их предотвращения.
Этап подготовки проекта
Риск персонала
Риски:
• Набор необученного персонала к выполнению проекта;
• Набор в состав разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых бизнес процессов;
• Неимение выработанной стратегии автоматизации№
• Отсутствие общих целей и задач проекта;
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка единой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
Риски:
• Ошибочное определение рамок и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методов решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержка стабильности границ проекта, которые выделяются еще
на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
• Согласованное и утвержденное проектное решение;
• Высокий порог принятия изменений.
Риск неверного планирования
Риски:
• Неэффективный план организации разработки системы;
• Несоблюдение сроков выполнения работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый доступ
к этим данным для всех участников проекта.
Этап разработки
Риск персонала
Риски:
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;
• Ошибочное представление задачи проектирования;
• Набор разработчиком без опыта работы с подобными системами.
Методики предотвращения:
• Грамотный набор сотрудников, участвующих в проекте;
• Реализация четкой системы коммуникации между сотрудниками,
постоянное документирование изменений в системе.
Технические риски
Риски:
• Остановка разработки из-за ошибок в применяемом ПО;
• Пользовательская документация включает в себя описание не всех
функции системы.
Методики предотвращения:
• Работа только с проверенным лицензионным ПО, регулярное
резервное копирование данных;
• Отслеживание полноты сведений во всех документах.
Этап внедрения
Риск персонала
Риски:
• Разрозненность деятельности разработчика и специалистов
предметной области;
• Отсутствие желания у сотрудников использовать новую систему и
связанные с этим трудности их обучения;
• Безучастность руководства.
Методики предотвращения:
• Обучение пользователей со стороны заказчика методики работы с
системой;
• Подготовка плана внедрения системы;
• Обоснование важности и нужности автоматизации персоналу;