76
документов, определяющих ЖЦ именно программных продуктов. Здесь помимо
ГОСТ Р ИСО/МЭК 12207-2010 можно перечислить такие стандарты как [2]:
ГОСТ 34.601-90 - распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные
в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
Методические разработки компании Oracle «Custom Development Method»
(Oracle CDM) по разработке прикладных информационных систем. Они содержат
технологический материал, детализированный до уровня заготовок проектных
документов, рассчитанных на использование в проектах с применением Oracle.
Применяется для классической модели жизненного цикла, а также для технологий
«быстрой разработки», рекомендуемых в случае малых проектов.
Rational Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение и
внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате
которых выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки, каждый
цикл завершается генерацией версии системы. Если после этого работа над проектом
не прекращается, то полученный продукт продолжает развиваться и снова минует те
же фазы.
Разработка Microsoft Solution Framework (MSF) в значительной степени
схожа с RUP, так же включает четыре фазы: анализ, проектирование, разработка,
стабилизация, является итерационной, предполагает использование объектно-
ориентированного моделирования. MSF в сравнении с RUP в большей степени
ориентирована на разработку бизнес-приложений.
Новая методология Extreme Programming (Экстремальное
программирование - XP) сформировалось в 1996 году, в ее основе лежит командная
работа, эффективная коммуникация между заказчиком и исполнителем в течение
всего проекта по разработке ИС, а разработка ведется с использованием
последовательно дорабатываемых прототипов.
Сразу исключим из рассмотрения методологию Extreme Programming и
Microsoft Solution Framework, так как они во многом повторяют ранее известные, а
77
также ориентированы на командную разработку. В данном же случае разработчик
один. Сравнение основных подходов к составу и наименованию стадий ЖЦ ПО
приведено в таблице 2.1.
Таблица № 2.1
Различные подходы к составу и наименованию стадий ЖЦ ПО
ГОСТ 34.601-90
Oracle CDM
RUP
Формирование требований
к ИС
Разработка концепции ИС
Техническое задание
Стратегический анализ
Начальная стадия
(Inception)
Эскизный проект
Технический проект
Проектирование
Разработка
(Elaboration)
Рабочая документация
Реализация
Конструирование
(Convarcharuction)
Ввод в действие
Внедрение
Эксплуатация и
сопровождение
Ввод в действие
(Transition)
Несмотря на появление новых тенденций, основные этапы разработки
программного обеспечения остаются неизменными, при этом разработчики
самостоятельно меняют эту последовательность исходя из требуемого набора
функций или сроков сдачи проекта [29]. Поэтому в данной работе будет принята
последовательность этапов, основанная на стратегии RUP, учитывая
ориентированность данной разработки на СУБД MS SQL Server.
Последовательность этапов приведена на рисунке 2.1.
Первый этап - планирование процесса разработки - содержательно
описывается в аналитической части пояснительной записки (выделен зеленым
цветом), а последующие этапы реализуются в ходе практической работы. Здесь же
кратко поясним содержание предстоящих этапов и обоснуем выбор тех или иных
стратегий их реализации.
На этапе проектирования основной акцент будет сделан на использовании
апробированных CASE-технологий, которые помимо поддержки организованного
управления проектами предоставляют разработчику возможность создания каркаса
программ.
78
Рисунок 2.1 - Этапы разработки системы регистрации обращений граждан
Специфика разрабатываемой автоматизированной системы заключается в
необходимости своевременной модернизации и адаптации под новые требования
пользователя, возникающие во время осуществления текущей деятельности
Агентства, проведении в жизни пенсионной реформы, оптимизации процессов
документооборота и по мере изменения законодательства. Исходя из данного
требования, было бы целесообразно применить спиральную модель жизненного
цикла автоматизированной системы [2]. Однако основная проблема спирального
цикла – определение момента перехода на следующий виток спирали в данном
случае будет ярок выражена, поскольку планирование таких изменений, как
правило, невозможно осуществить.
В связи с этим в данном дипломном проекте будет применена модель быстрой
разработки ПО - Rapid Application Development (RAD), которая используется при
наличии средств разработки графического интерфейса (включено в выбранную
среду Embarcadero Delphi XE8), структуры БД, кодогенераторов (Oracle).
В рамках данной модели разработка каждого продукта ограничивается 60
днями (что удовлетворяет данному проекту), а ролевое участие пользователя
состоит в выполнении следующих задач, рисунок 2.2:
79
этап планирования требований – сбор требований выполняется при
использовании рабочего метода, называемого совместным планированием
требований, который представляет собой структурный анализ;
пользовательское описание – совместное проектирование приложения
используется с целью привлечения пользователей, на этой фазе проектирования
системы работающая над проектом команда использует автоматические
инструментальные средства, обеспечивающие сбор информации;
фаза конструирования – фаза объединяет детальное проектирование,
построение (кодирование и тестирование), постановку ПО;
перевод на новую систему - фаза приемочных испытаний, внедрение и
обучение персонала.
Рисунок 2.2 - Модель быстрой разработки RAD
К числу достоинств данной модели стоит отнести малое время цикла
разработки и малое количество специалистов (в данном случае разработчик один) и
относительно небольшие трудозатраты, вследствие чего снижаются риски,
связанные с соблюдением графика. При этом за счет активного привлечения
80
заказчика на этапе преддипломной практики снижается риск его
неудовлетворенности, а также эффективно используются имеющиеся средства и
структуры.
Среди недостатков модели выделяют высокую вовлеченность пользователей
в процесс разработки, что требует от них достаточно высокой квалификации. При
этом сроки разработки могут необоснованно затянуться, а конечный результат
может оказаться нечетко выраженным. И от разработчика требуется ускорение на
этапе конструирования.
На стадии внедрения проводятся подготовка и постепенное освоение
разработанной проектной документации ИС заказчиком. В процессе выполнения
работ на этой стадии осуществляется выявление частных и системных недоработок
в предлагаемом для внедрения проектном решении [5].
В настоящее время рассматриваются четыре способа внедрения новой
информационной системы:
«Параллельная стратегия».
«Скачок».
«Пилотный проект».
«Узкое место».
Стратегия «Параллельное использование» подразумевает, что параллельно
выполняются старая и новая технология решения задачи, их результаты
сравниваются. Если результаты согласуются длительное время, то осуществляется
переход на новую технологию.
При стратегии «Скачок» старая технология работает до определенного
момента, затем осуществляется внедрение новой технологии, а после внедрения
реализуется только новая технология. Это может стимулировать пользователей
системы к быстрому ее освоению, однако возникает большая вероятность остановки
технологического процесса получения и обработки информации при условии, если
в новой системе возникнет сбой.
Стратегия «Пилотный проект» применима к ограниченному числу
процессов, областью применения обычно является небольшой участок. При этом
снижаются риски выбора неверного решения, что не приводит к длительному
простою всего подразделения, а также появляется возможность изменения
81
планируемой технологии в процессе внедрения ИС на участке. Однако здесь
присутствует сложность интеграции информационных потоков формируемых по
старой и новой технологии, а также необходимость управления старой и новой ИС
одновременно.
Стратегия «Узкое место» предполагает автоматизацию малой части
технологического процесса, который обычно выбирается по критериям, их
эффективности приводящих к повышению качества реализации процессов только в
определенном узком месте. При этом после автоматизации каждого узкого места
имеется возможность прервать автоматизацию, а требования к уровню
планирования работ внедрения минимальны. При этом независимость
автоматизации узких мест может привести к формированию избыточного множества
программно аппаратных решений.
Специфика работы клиентской службы Управления делами АССП
предполагает невозможность приостановки ее работы из-за внедрения новой ИС,
поскольку это может повлечь нарушение законодательства Республики
Таджикистан и социальную напряженность среди уязвимой части населения -
пенсионеров. Следует предусмотреть также, что риск влияния неудачного
внедрения на эффективность работы ведомства должен быть минимальным или
отсутствовать. При этом существующая бумажная технология практически
неуязвима для внедрения новой ИС, так как может существовать параллельно и
независимо от нее. При этом потребуется лишь большее отвлечение сотрудников на
обучение. Решаемая задача изначально решается на одном участке, переход на
уровень всего предприятия в целом не запланирован.
Поэтому принципиально неприемлемы такие способы внедрения как «узкое
место» и «скачек». Для выбора лучшего варианта из оставшихся способов -
«параллельной стратегии» и стратегии «пилотного проекта», проведем их
сравнительную характеристику, представленную в таблице 2.2.
Таблица № 2.2.
Сравнительная характеристика стратегий внедрения ИС.
Способ
Критерий
Параллельная стратегия
Пилотный проект
82
Случай применения
Старую работающую
систему необходимо
заменить новой
Тактика «скачка», но
применяемая к
ограниченному числу
функций
Область применения
Не имеет значения
Малый участок
деятельности
Риск срыва работы
подразделения
Риск минимальный
Стратегия нацелена на
снижение риска при
внедрении
Дублирование операций
Есть
Нет
При использовании параллельной стратегии внедрения проекта одновременно
работают старая и новая системы, что требует двойной загрузки на персонал. Однако
при замене одной части программного обеспечения другой дублирование операций
при внедрении системы не будет иметь принципиального значения для выбора
способа внедрения. Гораздо более важно снизить риск срыва работы подразделения.
В этой связи наиболее приемлемой представляется стратегия параллельного
внедрения.
Этап эксплуатации или сопровождения системы на участке автоматизации
динамично меняющихся технологических процессов в организации представляет
собой довольно сложную задачу. Модернизация программно-аппаратной части,
вызванная физическим и моральным старением компонентов АСУ; необходимость
отслеживания изменений в законодательстве; необходимость доработки системы
под новые требования ее пользователей; обеспечение безопасности информации в
процессе эксплуатации - эти и многие другие вопросы постоянно встают перед
персоналом, ответственным за процесс. На этой стадии выполняются этапы
эксплуатации проекта и сопровождения и модернизации.
Первый этап подразумевает исправления в работе всех частей системы при
возникновении сбоев, регистрацию этих случаев в журналах, отслеживание технико-
экономических характеристик работы системы и накопление статистики о качестве
работы всех компонентов системы.
В дальнейшем при сопровождении и модернизации осуществляются анализ
собранного статистического материала, соответствия параметров работы системы
требованиям окружающей среды. В конечном итоге результаты такого анализа
83
позволяют сделать заключение о необходимости модернизации всего проекта или
отдельных его компонентов, определить объемы доработок, сроки и стоимость их
выполнения.
При решении поставленной задачи автоматизации разработка проекта
производится собственными силами, без привлечения специалистов со стороны.
Поэтому сопровождение проекта и его эксплуатация будут осуществляться
внутренними силами, то есть персоналом Управления информационных технологий
АССП.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
При осуществлении любого проекта всегда возникает ситуация, связанная с
неопределенностью, неполнотой или неточностью информации об условиях
реализации проекта и связанных с ними затратах и результатах. Все участники
проекта заинтересованы в том, чтобы исключить возможность провала проекта из-
за таких неопределенных ситуаций. Для того чтобы снизить потери от возможных
просчетов и избежать провала проекта в целом, методология управления проектами
предусматривает специальные процедуры, помогающие учесть факторы
неопределенности и риска на всех фазах и этапах проекта.
Проекты в области информационных технологий обладают специфическими
характеристиками, в силу которых эффективное управление рисками становится
жизненно важным для их успеха. Изменяющиеся требования пользователей, новый
инструментарий и новые технологии, растущие угрозы для информационной
безопасности, текучесть кадров – все это дополнительные факторы, способные
повлечь за собой изменения в проекте и заставить проектную группу принимать
решения в условиях неопределенности (риска). В основе управления рисками лежит
их формулировка, т.е. выражение естественным языком причинно-следственной
связи между реально существующим фактором проекта и потенциально возможным,
еще не случившимся событием или ситуацией.
Основные риски для этапа планирования требований и пользовательского
описания в рамках выбранной модели разработки приведены в таблице 2.3.
Таблица № 2.3
84
Основные риски разработки проекта автоматизации регистрации обращений
граждан на этапе планирования требований
№
Риск
Содержание риска
Способы предотвращения
1
Риск
персонала
Привлечение неопытного
персонала к выполнению
проекта.
Включение в состав
разработчиков «случайных»
сотрудников, а не ключевых
участников автоматизируемых
бизнес процессов
Отсутствие единой стратегии
автоматизации
Отсутствие единой цели и задачи
проекта
Отсутствие мотивации
сотрудников
Негативное отношение персонала
к проекту
Необдуманный план ведения
работ
Активное взаимодействие с
руководством в ходе проекта и
своевременное принятие
решений.
Участие в проекте ведущих
специалистов и
профессиональных
консультантов
Четко сформулированные цели
проекта
Проработка общей стратегии
автоматизации организации
Стабильный состав рабочей
группы в течение всего проекта
2
Риск ведения
проекта
Неверное определение рамок и
масштаба проекта
Проектирование ошибочных
функций системы
Выбор неправильных технологий
и методов решений задач
Не соблюдение требования
заказчика
Обеспечение стабильности
границ проекта, которые
определяются на начальном
этапе и остаются неизменными
вплоть до окончания проекта.
Качественное планирование
выполняемых работ
Обеспечение проекта
необходимыми ресурсами
Утверждение и согласование
проектного решения
Установление высокого порога
принятия изменений
3
Риск
неверного
планирования
Неэффективный
организационный план внедрения
системы
Срыв сроков выполнения работ по
этапам
На ранних стадиях проекта
проведение аудита, организация
командной работы,
распределение ролей и
стимулирование.
Документирование всех работ и
обеспечение доступа к данным
всем участникам проекта
Основные риски для этапа конструирования в рамках выбранной модели
разработки приведены в таблице 2.4.
Таблица № 2.4
85
Основные риски автоматизации регистрации обращений граждан на этапе
конструирования
№
Риск
Содержание риска
Способы предотвращения
1
Технический
риск
Приостановка разработки из-за
ошибок в используемом
программном обеспечении.
Пользовательская документация
охватывает не все функции
системы.
Использование только
проверенного лицензионного
ПО, проведение регулярного
резервного копирования
данных
Проверка документации на
полноту сведений
Основные риски для этапа перехода на новую систему (внедрения) в рамках
выбранной модели разработки приведены в таблице 2.5.
Таблица № 2.5
Основные риски автоматизации регистрации обращений граждан на этапе перехода
на новую систему (внедрения)
№
Риск
Содержание риска
Способы предотвращения
1
Риск
персонала
Несогласованность действий
разработчика и специалистов
предметной области
Нежелание сотрудников
работать с новой системой и
связанные с этим трудности их
обучения
Неучастие руководства в проекте
Обучения сотрудников
заказчика работе с системой
Составление плана внедрения
системы
Обоснование необходимости
автоматизации персоналу
Вовлечение руководства в
проект и активное
взаимодействие с ним в ходе
всего проекта.
2
Технические
риски
Потеря данных при внедрении
системы
Привлечение
квалифицированных
сотрудников, имеющих опыт в
подобных проектах
Основные риски для этапа перехода на новую систему (эксплуатации и
сопровождения) в рамках выбранной модели разработки приведены в таблице 2.6.
Таблица № 2.6
Основные риски автоматизации регистрации обращений граждан на этапе перехода
на новую систему (эксплуатации и сопровождения)