55
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл. Это понятие – одно из базовых понятий в информаци-
онном менеджменте. Жизненный цикл информационных систем – это последо-
вательный и непрерывный процесс, который начинается с момента зарождения
идеи и принятия решения о создании ИС, и заканчивается выводом ее из экс-
плуатации.
Характерная черта жизненного цикла – это то , что он охватывает все ста-
дии ее проектирования, создания, сопровождения, поддержки, и развития:
анализ предметной области и формирование инфологической и
функциональной моделей, характеризующих целевой объект ИС;
проектирование, которое заключается в разработке решений, со-
гласно утвержденному техническому заданию (далее – ТЗ);
разработку системы, ее тестирование, анализ на соответствие всем
спецификациям;
глубокое тестирование ИС и поиск сбоев, с их последующим
устранением;
внедрение системы в эксплуатацию, с использованием той или
иной модели внедрения;
сопровождение системы;
развитие и расширение ИС.
На сегодняшний день существуют различные стандарты, которые регла-
ментируют жизненный цикл ПО, а иногда затрагивают и процессы проектиро-
вания и разработки. Вот некоторые из них [19].
56
ГОСТ 34.601-90 - распространяется на автоматизированные систе-
мы и регламентирует этапы их создания. Также, в стандарте со-
держится описание комплексов выполняемых работ на каждом эта-
пе. Стадии работ, описываемые данным стандартом, соответствуют
в большей степени каскадной модели ЖЦ.
ISO/IEC 12207:1995 – стандарт, описывающий процессы и органи-
зацию ЖЦ. Данный стандарт распространяется на все виды ПО,
разрабатываемого по заказу. Данный стандарт, однако, не содер-
жит описания фаз, стадий и этапов .
Custom Development Method (методика Oracle) – стандарт по раз-
работке ИС, который детализирован до уровня проектной докумен-
тации, рассчитанной на использование проектов, где задействованы
средства Oracle. Данный стандарт применяется в основном, для
классической модели жизненного цикла, с описанием всех этапов и
стадий, а также для технологий быстрой разработки приложений,
которые рекомендуются в случае проектов небольшого размера.
Rational Unified Process (RUP) предполагает и описывает итера-
тивную модель ЖЦ, которая включает фазы начала, исследования,
построения и внедрения. Эти фазы могут быть разбиты на итера-
ции, каждая из которых подразумевает выпуск версии, для общего
или тестового использования. Проходя через каждый из этапов,
продукт проходит цикл разработки. Каждый цикл завершается со-
зданием новой версии продукта. В дальнейшем, если продукт мо-
дернизируется, то он проходит по новой через все эти же стадии.
Microsoft Solution Framework (MSF) также сходен с RUP, и тоже
включает в себя 4 фазы: анализ, проектирование, разработку, ста-
билизацию; он является итерационным и предполагает использова-
ние средств объектного моделирования. Данный стандарт ориенти-
рован в большей степени на разработку различных бизнес-
приложений.
57
Стандарт ISO/IEC 12207 не содержит какой-либо конкретной модели
жизненного цикла и описаний стадий и методов разработки, рекомендации яв-
ляются общими для всех моделей ЖЦ. Под моделью же часто подразумевается
структура, которая определяет общую последовательность стадий и взаимосвя-
зи различных процессов, действий и оперативных задач на протяжении всего
ЖЦ.
В современных условиях развития информационных технологий мы име-
ем три основные модели жизненного цикла:
каскадная;
спиральная;
поэтапная.
Каскадная («водопадная») модель жизненного цикла – подразумевает
пошаговый процесс разработки. При этом переход от одного этапа к другому
происходит только после того, как первый этап полностью завершится (рис.
11).
Рис. 11. Каскадная модель ЖЦ
В спиральной модели разработка программного обеспечения происходит
как бы по нарастающей. Сперва, на первом этапе, проходит разработка системы
на высоком уровне абстракции, а дальше, виток за витком, разработка конкре-
тизируется в большей степени (рис. 12).
58
Рис.12 Спиральная модель жизненного цикла
Поэтапная модель жизненного цикла в целом сходна с каскадной. Ее
главное отличие заключается в том, что каждый этап представляет собой как
бы собственный «микро жизненный цикл». В данной модели не обязательно
выполнения условия непременного завершения предыдущего этапа, и всегда
возможно перейти на предыдущие этапы, с целью уточнения, модернизации, и
улучшения. Таким образом, поэтапная модель является усовершенствованной
моделью каскадного цикла (рис. 13).
Рис. 13 Поэтапная модель жизненного цикла
59
После тщательного анализа вышеприведенных моделей ЖЦ, с учетом их
особенностей, достоинств и недостатков, было принято решение, что для теку-
щего проекта автоматизации приема и учета заявок на техническое обслужива-
ние клиентов ОГАУ "Информационно-технический центр Иркутской области" ,
в наибольшей степени подходит каскадная модель жизненного цикла. Это обу-
словлено тем, что переход к следующему этапу разработки происходит только
после завершения предыдущего (что в данном случае, с учетом специфики по-
ставленной задачи, является логичным), включая подготовку пакетов докумен-
тационной поддержки, достаточной для продолжения работ по модернизации
будущей системы группой других разработчиков в дальнейшем. Также модель
позволяет планировать сроки завершения работ, и подсчитать затраты на их
выполнение [27].
Каскадный метод очень хорошо подходит для проектирования систем,
когда в начале разработки есть возможность точно и в полной мере сформули-
ровать все требования, дабы предоставить программистам свободу действий по
их реализации, оптимальной с технической точки зрения. Однако, в случае, ес-
ли в процессе разработки будут обнаружены ошибки, допущенные на преды-
дущем этапе, то придется прибегать к декомпозиции и энтраверсии проекта,
что сделает реальную схему применения модели примет другой вид (рис. 14).
Рис.14 Реальная модель реализации проекта с
использованием каскадной модели ЖЦ
60
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В рамках любого проекта по созданию ИС в организации, всегда суще-
ствует множество различных задач, которые связаны с общим менеджментом
проекта, разработческой деятельностью, проектными изысканиями, процессом
внедрения системы, каждая из которых тоже может считаться проектом, име-
ющим собственные особенности и нюансы. Неудивительно, что в такой слож-
ной и порой непредсказуемой разработке всегда существуют разного рода рис-
ки.
Риски заказчика, чаще связаны с неполным выполнением целей проекта,
неэффективно освоенными средствами, а риски исполнителя проекта – с воз-
можностью сильного превышения стоимости работ по сравнению с расчетно-
плановыми. Многократное возрастание риска проекта также связано с необхо-
димостью ведения параллельных работ, иногда принципиально отличающихся
по своему характеру.
Наиболее характерные риски и методы из минимизации приведены в таб-
лице 3.
Таблица 3.
Возможные риски проекта и способы их минимизации
Виды рисков /менеджмент рис-
ков
Уменьшение рисков
Уменьшение вероятности риска
Риски масштаба проекта
Тщательный анализ этапов, взаимо-
действия разработчиков на каждом из
них.
Выверенная программа проверки каче-
ства, управление конфигурацией проек-
та, регламент взаимодействия всех
участников проекта.
Риски, связанные с малоопытно-
стью членов проекта
Обучение пользователей, включая
руководителей, соблюдение регла-
мента работы.
Утверждение концепции проекта, жела-
тельно охватив начальную его стадию.
Технологические и технические
риски
Отбор команды проектировщиков по
квалификации. Обучение участников
проекта, контроль за их работой.
Использование стандартизации пред-
приятия на проведение проектных ра-
бот, разработка регламентов проекта.
Организационные риски
Обучение всех участников проекта,
тренинги, семинары, формализация
деятельности в максимальной мере.
Ролевая диверсификация проекта, при-
влечение в команду разработчиков
опытного ответственного администрато-
ра.
Операционные риски
Тестирование, тестирование и еще
раз тестирование… Экспертиза доку-
ментации.
Строгое следование регламенту проце-
дур проверки и оценки качества про-
дукта.
2.2 Информационное обеспечение поставленной задачи
2.2.1 Описание информационной модели процесса
Информационная модель – это структурная схема движения и организа-
ции всех элементов информационных потоков и функций рассматриваемой
предметной области. Она показывает, на основе каких входных данных и доку-
ментации и какой нормативно-справочной информации осуществляется реали-
зация всех функций по обработке данных, а также формирование всей сопут-
ствующей выходной документации. Информационная модель проиллюстриро-
вана на рис.15.
Рис. 15 Схема информационной модели разрабатываемой
системы
63
В соответствии с вышеуказанной моделью, менеджер заполняет справоч-
ник «состояние проектов». Затем, с использованием данных из других справоч-
ников («клиенты», «Сотрудники», «Города», «Фирмы»), состояния текущих
проектов, менеджер изменяет состояние таблицы «Проекты». На основании
данных оттуда, с учетом данных справочника «Состояние проектов», менеджер
получает выведенные экранные формы для выходных документов, например,
таких как список проектов и список стадий выполнения работ.
2.2.2 Системы кодирования. Используемые классификаторы.
В рамках рассматриваемого комплекса задач, в составе информационного
обеспечения ИС, ключевое место принадлежит классификаторам экономиче-
ской информации. В числе их задач, обеспечение сжатия показателей, таким
образом сокращая объем хранимых данных в компьютере и время на поиск ин-
формации, требуемой для решения задач, а также облегчение обработки ин-
формации. Именно эту задачу и позволяют выполнить классификация и коди-
рование данных.
Классификатор представлят собой документ, при помощи которого про-
изводится формализация описания информации в ЭИС, и содержащий в част-
ности, наименования объектов, классификационных группировок, включая их
кодовые обозначения. Классификаторы можно разделить на группы, по их
применению [21]:
1. Общегосударственные – используются во всех отраслях и на всех
уровнях менеджмента, для унификации повсеместного обозначения объектов;
2. Локальные – используются в пределах групп организации или на па-
раллельных уровнях менеджмента;
3. Отраслевые – применяются в пределах отдельной отрасли или ведом-
ства.
64
С целью полной формализации информации, простая классификация не-
достаточна. С целью усиления степени формализованности информации,
обычно прибегают к процедуре кодирования.
Кодирование представляет собой процесс присвоения объектам и груп-
пам их условных обозначений, которые соответствуют выбранной системе ко-
дирования информации.
Совокупность правил условных обозначений объектов и групп с исполь-
зованием различных кодов составляет так называемую Систему кодирования.
Код – это условное обозначение групп и объектов в виде знака, группы
знаков, в полном соответствии с принятой системой кодирования. Все суще-
ствующие системы можно сгруппировать в два раздела: классификационные и
регистрационные системы кодирования.
Ниже сформированы требования, которым удовлетворяют разрабатывае-
мые для ИС классификаторы:
полнота охвата признаков классификации каждым классификато-
ром;
согласованность деления множеств объектов с алгоритмами их об-
работки;
взаимно-однозначное соответствие между наименованиями объек-
тов и их условными (кодовыми) обозначениями;
простота кодирования и возможность автоматической классифика-
ции;
увязка с другими классами обозначений и классификаторами;
эффективное использование классификатора в обработке данных.