УДК 339.13:004
(100) + 004.62.001.2-52
Л.К. Бобров
доктор техн. наук, профессор кафедры
экономической информатики
Новосибирского государственного
университета экономики и управления
ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА СОЗДАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ
КАК ПРОЦЕСС
Приводятся маркетинговая и
инженерная трактовки понятия жизненного цикла информационного продукта.
Жизненный цикл проекта создания информационной системы (ИС) рассматривается как
процесс,
состоящий из трех перекрывающихся стадий. Дается краткое описание этапов
создания ИС
и формулируются базовые принципы взаимодействия заказчика с разработчиком.
1. Маркетинговая модель
жизненного цикла
Одним из важных моментов при
определении стратегии и практических действий любых предприятий, в т.ч. и
информационных организаций в условиях рынка является анализ жизненного цикла
информационной продукции и услуг
В маркетинге анализ кривой
жизненного цикла является источником выработки маркетинговых стратегий,
адекватных соответствующему этапу жизненного цикла продукции
Различают жизненный цикл продукта, технологии, отдельной организации либо
отрасли в целом, который, по сути, является суммарной величиной жизненных
циклов соответствующей группы продукции – аналогов по физическим
характеристикам или потребительскому назначению.
Классическая кривая жизненного цикла имеет S-образный характер и показывает
изменение объема продаж во времени (рис. 1). В зависимости от объемов продаж
выделяется четыре стадии жизненного цикла продукции: выход на рынок, рост,
насыщение и спад, что соответствует Ф. Котлеру, который определяет жизненный
цикл товара как “процесс развития продаж и получения прибылей, состоящий из
четырех этапов: этапа выведения на рынок, этапа роста, этапа зрелости и этапа
упадка”
Рис.
1.
Кривые жизненного цикла спроса, технологии и продукта
Этап вывода на
рынок сопровождается небольшим, но плавным ростом объемов продаж, причем как
правило, получаемые на этом этапе доходы не покрывают расходов. На этапе роста
рынок завоеван, и рост объема продаж позволяет покрывать расходы. Этап
насыщения характерен наибольшим объемом продаж при стабилизации расходов и
товар приносит устойчивую значительную прибыль. Последний этап – этап спада –
сопровождает процесс исчезновения товара с рынка, когда спрос на товар все
больше и больше снижается вплоть до полной остановки производства данного
товара.
Понятно, что выпуск
полной палитры информационной продукции, называемой в маркетинге портфелем,
должен быть организован таким образом, чтобы в фиксированный момент времени
различные продукты находились в различных стадиях жизненного цикла и возможный
убыток от одних продуктов покрывался прибылью от других.
Следует отметить,
что современная тенденция – сокращение длительности жизненного цикла товара при
все большем времени, требуемом для его создания, непосредственно касается
информационной продукции как одного из видов наукоемкой продукции. Однако
выведенный на рынок товар начинает приносить прибыль далеко не сразу. Поэтому
естественным стремлением является сокращение длительности разработки продукта и
периода вывода его на рынок, когда прибыль отрицательна. С другой стороны,
желательно как можно более продлить во времени фазу зрелости продукта, когда
спрос максимален, а прямые издержки и накладные расходы идут на убыль.
2. Инженерные модели жизненного
цикла
На рис. 2 показано изменение во
времени не объема продаж, как на рис. 1, а объема прибыли от реализации
информационного продукта.
Рис. 2. Динамика изменения прибыли от реализации
информационного продукта
Здесь точка
пересечения пунктирной линии с осью абсцисс t1 соответствует
точке начала координат, приведенной на рис. 1, т.е. моменту окончания
разработки и вывода продукта на рынок. На протяжении времени от момента t0 до
момента t2 прибыль отрицательна, т.е. в это время осуществляется
инвестирование разработки продукта и его выведения на рынок. В момент t2 суммарная
выручка от продаж становится равной сумме инвестиций, и кривая прибыли
переходит в положительную область.
В инженерных моделях
жизненного цикла рассматривается период времени от t0 до
t1,
т.е. от момента начала до момента завершения разработки программного продукта
(или информационной системы).
Появление в 2001
году разработанной Госстандартом России серии рекомендаций с общим названием:
“Информационные технологии поддержки жизненного цикла изделия” (рис. 3)
заложило основы отечественной нормативной базы, регламентирующей процессы
поддержки жизненного цикла.
Р50.1.027-2001. “Информационные
технологии поддержки жизненного цикла изделия. Автоматизированный обмен технической
информацией. Основные положения и общие
требования”.
Р50.1.028-2001.“Информационные
технологии поддержки жизненного цикла изделия. Методология функционального
моделирования”.
Р50.1.029-2001.“Информационные технологии поддержки жизненного цикла изделия.
Интерактивные электронные технические руководства. Общие требования к
содержанию, стилю и оформлению”.
Р50.1.030-2001. “Информационные технологии поддержки жизненного цикла
изделия. Интерактивные электронные технические руководства. Логическая структура
базы данных”.
Р50.1.031-2001.“Информационные технологии поддержки жизненного цикла
изделия. Терминологический словарь. Часть 1. Терминология, относящаяся к стадия
жизненного цикла продукции”.
Р50.1.032-2001.“Информационные технологии поддержки жизненного цикла
изделия. Терминологический словарь. Часть 2. Основные термины и определения
методологии и функциональных объектов в стандартах серии ISO 1033.
Рис. 3. Стандартизация информационных технологий
поддержки жизненного цикла
3. Жизненный цикл проекта создания
информационной
системы как процесс
Жизненный цикл
проекта создания информационной системы (ИС) может быть представлен как
процесс, состоящий из трех перекрывающихся стадий (“исследование” →
“проектирование” → “разработка”), включающих этап разработки технического
задания, этап проектирования и этап разработки (рис. 4).
Разработка технического задания.
Основная цель этапа
разработки технического задания (ТЗ) состоит в определении и формулировании
детальных требований к ИС. На данном этапе осуществляются следующие работы:
– описываются
информационные потребности заказчика;
– определяются
функции, которые должна выполнять ИС;
– в
перечне функций выделяются наиболее приоритетные, требующие первоочередной
реализации;
– анализируются
имеющиеся массивы данных и определяются требования к преобразованию их форматов
по структуре и наполнению;
– анализируются
возможности и варианты использования в разрабатываемой ИС существующего в
организации программного и аппаратного обеспечения;
– уточняются
имеющиеся ограничения и определяется возможность реализации проекта в требуемые
сроки и в рамках установленного финансирования;
– разрабатывается
предварительный календарный план выполнения работ.
Результатом
выполнения данного этапа является разработка:
– перечня
и описания функций, выполняемых ИС;
– предварительной функциональной модели ИС;
– предварительной
информационной модели ИС;
– набора
требований заказчика к ИС;
– перечня
вариантов возможных решений.
На данном этапе итоговым завершающим документом является утвержденное
техническое задание.
Объем ТЗ зависит от
масштаба информационной системы. Это может быть ТЗ на систему (подсистему) в
целом, либо составное (сложное) задание, когда в дополнение к основному ТЗ
разрабатываются частные технические задания на отдельные компоненты, например:
– на подсистемы, комплексы задач ИС и т. п.;
– на средства технического
обеспечения и программно-технические комплексы;
– на программные средства;
– на информационные продукты и услуги.
В
этом случае в ТЗ на систему в целом включаются общие для всех подсистем (задач)
требования, а дополнительные (частные) технические задания отражают
специфические требования, предъявляемые к каждой из подсистем (задач).
Качество
разработки технического задания во многом определяет фактические затраты
времени и финансовых средств на создание ИС, а также качество решения требуемых
заказчику функциональных задач. Именно по этим причинам наиболее часто возникают
разногласия заказчика с исполнителями (разработчиками). В такого рода спорах,
отвечая на претензии заказчика, разработчики упрекают его в неумении четко,
полно и корректно описать поставленную задачу, а также в постоянном изменении
требований к создаваемой системе. Избежать подобных конфликтов не помогают и
ссылки сторон на то, что составленное ТЗ полностью отвечает действующим стандартам
и другим нормативным документам. По поводу последнего следует отметить, что в
ГОСТах действительно отражаются все основные требования к составу и содержанию
ТЗ, но формальное соответствие ТЗ ГОСТу вовсе не исключает ситуаций, когда
содержательная часть поставленной задачи отражена неполно либо даже
противоречиво. При согласовании целей и задач внедрения информационной системы
заказчик и разработчик зачастую разговаривают на разных языках. То, что
является очевидным для заказчика, далеко не всегда так же очевидно для
разработчиков. И наоборот, разработчики часто не считают нужным разъяснять
заказчику, что они имеют в виду, оперируя в разговоре (или пользуясь в рабочих
документах) привычными для них техническими терминами и выкладками, которые,
как они считают, должны быть априори понятны заказчику.
Пытаться предупредить такого рода
конфликты следует на самых ранних стадиях разработки. Для этого в основу
разработки ТЗ должен быть положен ряд важных принципов, следование которым во
многом позволит бесконфликтно соблюсти интересы обеих сторон. В числе этих
принципов упомянем следующие.
Принцип партнерства. Каждая из сторон (заказчик и разработчик) должна
рассматривать другую сторону как партнера, равно заинтересованного в успешной
разработке и внедрении ИС. Поэтому создание технического задания – один из
самых ответственных этапов совместной (что весьма важно!) работы как в смысле
обеспечения высокого качества ТЗ и в целом всей ИС, так и в смысле формирования
партнерских отношений между заказчиком и исполнителем.
Принцип компромиссов и взаимных
уступок. В любой спорной ситуации возможно
компромиссное решение, к которому можно прийти, не ущемляя интересов только
одной стороны. При этом каждая из сторон должна быть готова к разумным
уступкам.
Принцип итеративности. И заказчик, и разработчик должны понимать, что на
начальных этапах работ неизбежны ситуации, требующие итеративного повторения
некоторых работ на основе уточненных данных. Так, представляется весьма
сомнительным, чтобы при создании информационной системы даже сравнительно
небольшой сложности удастся с первой попытки разработать ТЗ такого качества,
чтобы в дальнейшем оно не потребовало никаких изменений и уточнений. Поэтому в
самом техническом задании должны быть предусмотрены возможности и механизмы его
корректировки и для этих случаев должна быть определена схема увеличения или
уменьшения финансирования проекта создания ИС.
Принцип конкретности и
согласованности ожидаемых результатов.
Достигается тщательным всесторонним описанием того, что заказчик хочет получить
по окончании проекта (вплоть до периодичности выдачи результатов – напр.,
отчетов, и полного перечня их параметров). При этом очень важна как предельная
конкретность в описании результатов, так и используемая терминология. В
противном случае возможно либо расширенное толкование ТЗ заказчиком, либо
суженное толкование ТЗ разработчиком.
Принцип прозрачности данных. Предполагает детальное описание входных и выходных
информационных потоков, их структуры, наполнения, источников, потребителей,
носителей информации, периодичности поступления информации, и т.п. Если источником
исходных данных служат некие документы, то в приложении к ТЗ необходимо
поместить заполненные формы этих документов (в случае приложения незаполненных
форм может возникнуть ситуация, что в форме документа некое поле присутствует,
и разработчик намеревается использовать это поле, но на предприятии оно никогда
не заполнялось, не заполняется, и, что самое интересное – заполняться не
будет). Если по результатам обработки данных в ИС предполагается выдача
отчетных форм, то необходимо установить не только структуру, содержание и
периодичность выдачи этих форм, но и привести образцы (желательно –
заполненных) отчетных форм в приложении к ТЗ.
Принцип персонализации ответственности. Во избежание ситуаций, когда задача создания
ИС ставится одними людьми (подразделениями предприятия), а согласовывать
результаты внедрения будут другие, в ТЗ необходимо указать ответственных за согласование
промежуточных и финальных результатов.
Структура и наполнение ТЗ регламентируются
отечественными нормативными документами вплоть до государственных стандартов.
Однако на практике нередки случаи, когда техническое задание составляется в
произвольной форме, определяемой по согласованию сторон, либо при составлении
ТЗ следуют фирменным методикам известных поставщиков автоматизированных систем
управления (напр., Microsoft Business Solutions). Однако вне зависимости от
того, какие нормативные документы положены в основу создаваемого ТЗ, полезно
привести рекомендательный аннотированный список разделов, отсутствие или
недостаточная проработка которых может привести к негативным последствиям как
для заказчика ИС, так и для ее разработчиков:
– описание проблемы
(задачи) – здесь необходимо четко определить и полно описать задачи, которые
ставятся перед исполнителем;
– описание ожидаемых
результатов от реализации проекта – следует конкретизировать, что заказчик
ожидает получить по окончании проекта, какие модули (функции, задачи) системы и
в каком объеме должны быть внедрены;
– описание
деятельности предприятия – здесь желательно привести бизнес-модель предприятия
и, возможно, дать предварительный анализ бизнес-процессов (хотя, как правило,
это делается на более поздних этапах проектирования ИС);
– описание входных и
выходных информационных потоков с приложением образцов первичных, отчетных
(выходных) и других документов, необходимых для реализации информационной
системы;
– описание этапов
внедрения проекта – предусматривает декомпозицию работ по проекту на
относительно независимые блоки (например, автоматизация отдельных задач и
подсистем) с указанием сроков начала и завершения каждого этапа, целей и задач,
объемов выполненных работ, ответственных лиц со стороны заказчика и
исполнителя, а также детальное описание шагов по реализации каждого этапа;
– описание
результатов выполнения каждого этапа проекта в предельно конкретном виде для
того, чтобы не возникало дискуссий по поводу критериев признания этапа (либо
проекта в целом) завершенным;
– описание процедур приемки результатов каждого
этапа проекта должно включать подробные характеристики процесса и технологии
тестирования системы заказчиком, критериев соответствия выполненных работ техническому
заданию и определение процедуры документирования приемки.
Этап проектирования.
На этапе проектирования
осуществляется преобразовании требований, изложенных в ТЗ, в детальные
спецификации информационной системы. В процессе выполнения работ устраняются
неясности и неоднозначности, детально прорабатываются функциональные модели и
задачи каждой подсистемы, определяются структуры информационных массивов и баз
данных, разрабатываются интерфейсы и прототипы экранов, строится общая
информационная модель информационной системы. Вносятся необходимые уточнения и
дополнения в перечень требований к отдельным компонентам разрабатываемой
системы, уточняются формы входных и выходных документов, детально описываются
технологические процессы переработки информации. При необходимости, для каждого
элементарного процесса разрабатываются прототипы экранных форм, интерфейсов,
отчетов, и т.п. Конкретизируются требования к обеспечению целостности и
непротиворечивости данных, полномочия различных групп пользователей по доступу
к данным, и др.
Собственно процесс проектирования
может базироваться на различных подходах. В частности, последние годы получили
распространение структурный и объектно-ориентированный подходы к проектированию
ИС.
Однако независимо от используемых подходов, моделей и методов проектирования
основными результатами проектирования являются:
– функциональные
модели ИС в целом и подсистем;
– общая
информационная модель ИС;
– детально
проработанные интерфейсы между автономно разрабатываемыми подсистемами;
– прототипы экранных
и отчетных форм, диагностических сообщений, и т.п.
Набор документов,
представляемых по завершении этапа, включает:
– описание проекта ИС;
– детальное описание
бизнес-процессов (“как есть”) с точки зрения функциональной структуры,
информационной структуры, потоков данных;
– детальное
описание бизнес-процессов (“как должно быть”) с точки зрения функциональной
структуры, информационной структуры, потоков данных;
– описание архитектуры обеспечивающих подсистем
(информационное, лингвистическое, организационное, техническое и др. виды
обеспечения);
– набор
функциональных спецификаций (внешняя и внутренняя спецификации).
Функциональные
внешние спецификации описывают реализацию информационной системы с применением
конкретных инструментов разработки. Функциональные внутренние спецификации
включают требуемые программисту описания форматов данных, алгоритмов,
интерфейсов ИС, и т.п.
Решение о составе и
наполнении проектных документов принимает руководитель проекта. При этом он
должен руководствоваться существующими стандартами и другими нормативными
документами.
Разработка
и сдача ИС в эксплуатацию.
Основная цель этапа
разработки состоит в создании и тестировании приложений ИС. На данном этапе
производится проектирование баз данных, определяются окончательные требования к
аппаратным ресурсам, завершается разработка комплекта проектной документации.
На основе моделей, разработанных на этапе проектирования, производится
итеративное построение реально действующей информационной системы, осуществляется
разработка и тестирование программных приложений ИС. После разработки отдельных
компонент информационной системы и их автономной отладки осуществляется
комплексное тестирование системы в целом и оформляется эксплуатационная
документация. На данном этапе производятся необходимые организационные
изменения, осуществляется обучение пользователей, производится приемочное
тестирование ИС.
Этап разработки
завершается вводом информационной системы в промышленную эксплуатацию и
подписание соответствующего акта приема-передачи ИС.
Заключение
Рассмотрение
жизненного цикла проекта создания информационной системы как процесса,
продуманная организация этого процесса и соблюдение сформулированных принципов
взаимодействия заказчика с разработчиком позволяют избежать многих ошибок, вследствие
которых появляются нетехнологичные и низкокачественные информационные системы,
не оправдывающие ожиданий конечных пользователей и библиотечного персонала.
|
