Содержание к диссертации
Введение
1. Глава I. Проблематика разработки социально-ориентированных информационных систем 12
1.1 Актуальность социально - ориентированных проектов и их особенности 12
1.1.1 Информационные потребности общества 12
1.1.2 Концепция «Электронное Правительство» 14
1.1.3 Программа «Электронная Москва» и режим «одно окно» 18
1.1.4 Особенности социально - ориентированных информационных систем 19
1.2 Анализ моделей жизненного цикла информационных систем 21
1.2.1 Анализ требований стандарта ГОСТ 34. 601-90 к жизненному циклу информационных систем 21
1.2.2 Обоснование преимуществ итерационного жизненного цикла разработки сложных информационных систем 25
1.2.3 Эволюция подхода к итеративности разработки информационных систем 27
1.3 Анализ отечественных стандартов регламентирующих создание информационных систем 29
1.4 Выводы к Главе 1 31
2. Глава II. Обоснование применения функционально-итерационного проектирования информационной системы «одно окно» 33
2.1 Характеристика объекта автоматизации 33
2.2 Анализ применимости задаваемого и предлагаемого способов разработки к созданию информационной системы «одно окно» на основании оценки их рисков 36
2.2.1 Адаптация методики FMECA для оценки рисков социально-ориентированных проектов 36
2.2.2 Оценка рисковых событий задаваемого и предлагаемого процесса разработки информационной системы «одно окно» 42
2.3 Разработка модели жизненного цикла информационной системы на осынове интеграции требований ГОСТ 34.601-90 и методики Rational Unified Process 47
2.4 Задачи определения функциональной модульности 52
2.4.1 Определение участников взаимодействия режима «одного окна» 52
2.4.2 Описание процесса подготовки документов в режиме «одного окна» 53
2.4.3 Определение функциональных требований разрабатываемой системы 54
2.4.4 Проведение структурной декомпозиции продукта на независимые функциональные подсистемы 55
2.5 Определение функциональности модулей информационной системы «одно окно» 57
2.5.1 Универсальная подсистема обработки обращений 57
2.5.2 Подсистема координации и мониторинга работы органов исполнительной власти города Москвы, городских организаций в режиме «одного окна» 58
2.5.3 Подсистема обработки запросов и взаимодействия 58
2.5.4 Подсистема интеграции и маршрутизации (информационная шина) 59
2.5.5 Подсистема ведения общесистемных справочников и классификаторов 59
2.5.6 Подсистема взаимодействия с общегородскими классификаторами и справочниками 60
2.5.7 Централизованная подсистема учета и хранения данных 60
2.5.8 Подсистема интеграционных адаптеров к информационным системам и ресурсам.61
2.5.9 Подсистема администрирования 61
2.5.10 Подсистема информационной безопасности 62
2.6 Выводы к Главе II 62
3. Глава III. STRONG Методика планирования функционально — итерационной разработки
информационной системы «одно окно» STRONG 64
3.1 Планирование работ функционально-итерационного проекта 64
3.1.1 Эволюция методики планирования при переходе к функционально-итерационным проектам 64
3.1.2 Разработка плана проекта 65
3.1.3 Представление проекта в терминах пооперационного перечня работ 66
3.1.4 Разработка плана итерации 68
3.2 Планирование проекта по созданию информационной системы «одно окно» 69
3.2.1 Критерии определения последовательности реализации подсистем 69
3.2.2 Обоснование последовательности реализации подсистем 71
3.2.3 Общий план проекта 73
3.2.4 План первой итерации 77
3.2.5 План второй итерации 79
3.2.6 План третьей итерации 80
3.3 Выводы к Главе III 81
4. Глава IV. Разработка информационной системы «одно окно» 83
4.1 Методика функционально-итерационной разработки информационной системы 83
4.1.1 Фаза Начало 83
4.1.2 Фаза Проектирование 86
4.1.3 Фаза Конструирование 94
4.1.4 Фаза Внедрение 99
4.2 Реализация функционально-итерационного проекта по разработке информационной
системы «одно окно» 103
4.2.1 Предпроектное обследование городских организаций, осуществляющих взаимодействие в рамках режима «одно окно» 103
4.2.2 Разработка начальной функциональности и описание административных процессов на первой итерации 104
4.2.3 Приращение функциональности информационной системы «одно окно» на второй итерации 115
4.2.4 Корректировка функциональности системы при учете изменившихся требований на третьей итерации 125
4.3 Выводы к Главе IV 138
5. Заключение 139
6. Библиография 144
- Актуальность социально - ориентированных проектов и их особенности
- Анализ применимости задаваемого и предлагаемого способов разработки к созданию информационной системы «одно окно» на основании оценки их рисков
- Эволюция методики планирования при переходе к функционально-итерационным проектам
- Методика функционально-итерационной разработки информационной системы
Введение к работе
Объектом исследования является процесс создания системы управления административными процессами органов исполнительной власти и городских организаций, осуществляющих подготовку, согласование и выдачу документов в режиме «одного окна» в городе Москве. Разработка системы управления административными процессами включает создание ИС «одно окно», программно-аппаратной и сетевой инфраструктуры, обеспечивающих реализацию прав граждан органами исполнительной власти города Москвы в рамках процесса выдачи запрашиваемых заявителями документов (справок, копий, выписок, согласований, разрешений, лицензий, аттестатов, удостоверений, документации и др.).
Автоматизация режима «одного окна» позволит:
повысить эффективность работы органов исполнительной власти и городских организаций;
реализовать права граждан на доступ к информации, необходимой для жизни и работы;
сократить время на подготовку конечного документа за счет информационных взаимодействий;
снизить административные барьеры между госорганизациями, участвующими в процессах подготовки и выдачи запрашиваемых заявителями документов;
обеспечить контроль и управление деятельностью служб «одного окна».
ИС «одно окно» относится к классу сложного социально -
ориентированного ПО, разработка которого осложнена комплексом проблем, важнейшими из которых являются:
структурная, функциональная и информационная сложность объекта автоматизации;
отсутствие полных аналогов;
наличие унаследованного ПО и необходимость его интеграции с разрабатываемой системой;
территориально распределенная и неоднородная среда функционирования;
большое количество участников проектирования, пользователей и заинтересованных лиц, разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и опыту;
значительная длительность жизненного цикла разработки и внедрения системы.
Следствием этих проблем является:
нечеткая и неполная формулировка требований;
недостаточное вовлечение пользователей в работу над проектом;
отсутствие необходимых ресурсов;
неудовлетворительное планирование и отсутствие грамотного управления проектом;
частое изменение требований и спецификаций;
недостаточная поддержка со стороны высшего руководства;
недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
Как результат этой ситуации по данным Standish Group [72]:
16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;
52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
31,1% проектов были аннулированы до завершения;
на 89% оказался превышенным бюджет проектов среднего класса, а срок выполнения - на 122%.
История развития объекта исследования. С указанными выше проблемами разработки качественного ПО мировое сообщество столкнулось в конце 60-х - начале 70-х годов прошлого века. В то время наметился, т. н. «Кризис программного обеспечения».
Выход из кризиса был найден в, разработке дисциплины программной инженерии (от англ. - software engineering) [71, 74], как совокупности инженерных методов и средств создания ПО на основе применения строгого систематического подхода к его разработке, эксплуатации и сопровождению
[5].
Фундаментальная идея программной инженерии - проектирование. ПО является формальным процессом^ который можно изучать и совершенствовать. Методологическую основу программной инженерии составляет понятие жизненного цикла изделия (продукта) как совокупности всех действий* которые необходимо выполнить на протяжении всей «ЖИЗНИ» ИЗДЄЛИЯ;
Первое упоминание о жизненном цикле разработки ИС было на встрече 22-х руководителей проектов: по разработке ПО в. 1968 году в Лондоне, где анализировались проблемы и перспективы проектирования, разработки, распространения- и поддержки программ. На этой встрече была предложена концепция жизненного цикла ПО (от англ: - Software1 Lifetime Cycle) как последовательности шагов-стадий; которые необходимо выполнить в < процессе создания-и эксплуатации ПО:
Наиболее: известными зарубежными стандартами жизненного цикла ПО являются [37]:
DOD-STD-2167 А, 1985 г. (уточнен в 1988 г.) — Разработка программных
средств для систем военного назначения. Первый формализованный и
утвержденный стандарт жизненного цикла для проектирования
программных средств, систем военного назначения по заказам
Министерства обороны США;
« MIL-STD-498, 1994г. - Разработка и документирование программного
обеспечения. Принят Министерством обороны США для замены DOD-STD-2167 А и ряда, других стандартов. Он предназначен для применения всеми организациями и предприятиями, получающими заказы Министерства обороны США;
IEEE 1074, 1995г. - Процессы жизненного цикла для развития
программного обеспечения. Охватывает полный жизненный цикл
программных средств, в котором выделяются шесть крупных базовых процессов, детализирующихся на 16 частных процессов, которые подразделяются в совокупности на 65 процессов-работ. Отечественными стандартами на этот объект стандартизации являются:
ГОСТ 34.601-90 - Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания (Взамен ГОСТ 24.601-86, ГОСТ 24.602-86) [12];
ГОСТ Р ИСО/МЭК 12207-99 - Процессы жизненного цикла программных средств [13].
Современное состояние объекта исследования. Проблема разработки ИС «одно окно» заключается в том, что существующие отечественные методики создания программных средств не учитывают особенности сложного социально-ориентированного ПО. Это объясняется тем, что нормативная база отечественных информационных стандартов устарела и не отвечает современным требованиям, а деятельность по созданию таких ИС была настолько актуальной, что сразу оказалась в ряду чисто практических задач.
Научной проработки некоторых аспектов этой проблемы частично касались специалисты в области создания- корпоративных ИС и автоматизации процессов организаций. Однако крупных обобщающих работ по данной теме нет. Существуют лишь отдельные интересные публикации, освещенные в периодической печати [50], материалах научно-практических конференций и семинаров, посвященных данной проблематике. Авторами этих публикаций и докладов являются как ученые, так и специалисты-практики С. Архипенков [4], А.П. Ершов, И.Н. Скопин [58], А. Коуберн [49], Д.А. Рассел [56], Л.Ф. Куликовский, В.В. Мотов [34], Ф.П. Брукс [7], А. Закис [22], А.Н. Юртаев [69]. Это подтверждает то, что теоретическая разработка проблем создания качественных и отвечающих современным требованиям социально-ориентированных ИС продолжает оставаться актуальным исследовательским направлением.
Недостатки объекта исследования. Рассмотрим, с какими трудностями может столкнуться проект по созданию социально-ориентированной системы
«одного окна», если его выполнять в соответствии с требованиями конкурсной документации.
Прежде всего, процесс разработки должен проходить по этапам ГОСТ 34.601-90. Основными недостатками этого ГОСТа является избыточность разделов, посвященных производственной автоматизации, а также большое количество требований и документов, связанных с аппаратным обеспечением.
Следует особо подчеркнуть, что в указанном ГОСТе жестко определена процедура разработки системы по т.н. «водопадному» жизненному циклу. Согласно ему создание ИС должно выполняться последовательно по стадиям: анализа требований, проектирования, разработки, сборки и тестирования, а переход на каждую последующую стадию осуществляется только после полного завершения работ на предшествующей, причем возврат на пройденные стадии недопустим, в связи с жесткой привязкой процессов к стадиям жизненного цикла.
«Водопадный» стиль к созданию программных средств предполагает, что проект может стартовать только после сбора и анализа всех требований к будущей системе, однако на практике такая ситуация встречается крайне редко. Согласно ряду исследований в начале проекта возможно извлечение не более 60% требований [60].
Приведенные выше особенности показывают, что основной проблемой «водопадного» жизненного цикла является рост риска проекта со временем, ввиду возрастающих затрат на устранение ошибок предыдущих этапов.
Очевидно, что данный подход не мог не подвергаться критике, достаточно полное собрание аргументов против него приведено в [8]. Такой подход применим для небольших проектов и в тех случаях, когда требования к системе строго определены и гарантированно не будут изменяться. Однако разработка социально-ориентированной ИС начинается на базе неполных требований, пожеланий, ограничений, а потому неизбежны гипотезы, предположения и допущения, часто не корректные. Положение усугубляется тем, что первоначально сформулированные требования устаревают, перестают отражать новое понимание целей и задач системы. Как следствие, заказчик получает не
нужную ему программу, а некий суррогат, который в лучшем случае удовлетворяет потребности частично, а в худшем — вовсе непригоден для применения.
Проведенный нами анализ существующих концепций разработки ПО, показал, что снижение рисков, обусловленных использованием «водопадной» методологии ГОСТа, при разработке ИС может быть достигнуто использованием т.н. «функционально - итерационного» жизненного цикла, позволяющего обеспечить рост эффективности проектных решений и снижение риска влияния на нее потенциальных ошибок проекта.
Согласно [40] идентификация рисков, угрожающих проекту при функционально - итерационном жизненном цикле осуществляется на более ранних этапах, когда еще можно эффективно и своевременно реагировать на них. Итерационный подход провозглашает принцип возвратно -поступательного развития, при котором проект разбивается на несколько-итераций, включающих все типы проектных работ. Целью итерации является выпуск работоспособного продукта (подсистемы), который развивается в дальнейшем путем обогащения функциональности и разработанного интерфейса, а также интеграцией с другими подсистемами. На каждой итерации жизненного цикла происходит корректировка ранее выявленных требований к системе и доопределение новых.
Целью диссертационной работы является повышение результативности создания социально - ориентированной ИС подготовки, согласования и выдачи органами исполнительной власти и городскими организациями документов, запрашиваемых заявителем, посредством разработки и применения методики функционально-итерационной разработки ИС.
Предметом исследования является функционально-итерационная технология разработки социально - ориентированной ИС «одно окно» в соответствии с положениями стандарта ГОСТ 34.601-90, соблюдение требований которого зафиксировано в конкурсной документации на систему.
Диссертационная работа направлена на изучение методик разработки сложных социально-ориентированных ИС, поиска и апробации на практике
новых методов проектирования, обеспечивающих снижение проектных рисков, соблюдения бюджетных и временных рамок проекта создания ИС «одно окно».
Научной проблемой решаемой в диссертационной работе является разработка и обоснование применимости функционально — итерационной модели жизненного цикла создания социально - ориентированной ИС «одно окно» с учетом требований и стадий выполнения проекта по ГОСТ 34.601-90.
Диссертационное исследование проводилось по следующим направлениям:
анализ повышения качества предоставления государственных услуг за счет реинжиниринга административных процессов и использования в деятельности органов государственной власти современных ИКТ;
систематизация способов проектирования сложных социально — ориентированных ИС и анализ их эффективности;
поиск путей повышения качества разработки сложных систем на основе анализа современных отечественных и зарубежных стандартов создания ПО;
применение положений функционально - итерационной модели > жизненного цикла ПО к разработке сложной социально — ориентированной ИС «одно окно».
На защиту выносятся:
адаптация коэффициентов значимости последствий, вероятности возникновения причин и обнаружения рисковых событий для анализа выполнимости процессов разработки социально-ориентированных проектов на основе оценки их рисков;
общая архитектура ИС «одно окно», структура и инфраструктура компонентов системы и их взаимодействия;
адаптация положений стандарта ГОСТ 34.601-90 для представления жизненного цикла функционально-итерационной разработки ИС на примере создания системы «одно окно»;
методика функционально - итерационной разработки ИС «одно окно».
Актуальность социально - ориентированных проектов и их особенности
В конце 80-х - начале 90-х годов XX века в развитых странах было стремление изменить парадигму государственного управления, т.к. централизованные вертикальные монополии оказываются слишком медлительными, неоперативными и просто неспособными на перестройку и инновации в мире быстрых изменений, технологической революции, глобальной экономической конкуренции, дифференцированных рынков, высокообразованной рабочей силы, требовательных потребителей, а также строгих фискальных правил [11].
Эти же недостатки относятся и к иерархическим, бюрократическим организационным структурам государства, которые в современных условиях уже не способны гибко и эффективно осуществлять управленческие процессы [28]. Задача государственных органов заключается в том, чтобы перейти от бюрократической модели управления к процессной.
Бюрократическая модель ориентирована на решение типовых проблем в соответствии с традиционно заданными (исторически сложившимися) алгоритмами [54]. При этом закономерное усложнение решаемых задач стимулирует экстенсивный рост численности административного аппарата при незначительной модификации соответствующих алгоритмов решения управленческих задач. Действительно, наращивание «слоев» управленческой пирамиды стимулирует как процесс усиления централизации бюрократической организации, так и формирование многократно дублированных подсистем, контролирующих корректность генерации и передачи управленческих сигналов, а также повышающих степень связности организационной структуры [38].
Очевидно, что такая стратегия становится со временем неоптимальной, т.к. увеличиваются затраты на поддержание в рабочем состоянии органов исполнительной власти, что приводит к расходам государственного бюджета и дефициту бюджетных средств [25]. Но более серьезные недостатки бюрократической организации государственной системы заключаются в неоправданно длительном управленческом цикле. Выходом из данной ситуации может быть переход к процессной модели управления.
Процессная модель организации опирается на процессы самоорганизации, самокоординации всех ее элементов - индивидуумов и групп. Взамен жестких вертикальных связей формируется сеть горизонтальных взаимодействий. Управленческие алгоритмы приобретают гибкость, а группы, ответственные за решение возникающих задач, формируются по-новому, исходя из их задач, сложности и специфики [52].
В наиболее всеобъемлющей форме процессная модель организации применительно к системе государственного управления находит свое отражение в идее «электронного правительства».
Согласно формулировке SAGA (Германия), «электронное правительство» охватывает все аспекты управленческих процессов (принятия решений), в том числе процессов оказания услуг в той степени, в какой эти процессы опираются на использование ИКТ. Данный термин охватывает широкий спектр явлений, начиная от модернизации управленческих процессов на основе менеджмента «потоков работы», обеспечения доступа к правительственным информационным ресурсам через Интернет-порталы государственных ведомств до осуществления сложных транзакций и интерактивных сервисов для граждан через Интернет [30].
В государственной стратегии США внедрение «электронного правительства» понимается как использование Интернет - технологий для облегчения взаимодействия граждан и бизнеса с правительством, сохранения средств налогоплательщиков и рационализации связей государства и населения. При этом подчеркивается, что «электронное правительство» не сводится лишь к простому размещению различного числа форм официальных документов в Интернете, а означает обеспечение полного доступа населения и бизнеса к сервисам и информации на основе использования ИКТ [31].
В официальных документах Правительства Канады «электронное правительство» определяется как обеспечение доставки услуг гражданам с помощью электронных технологий. При этом онлайновое правительство подразумевает предоставление услуг клиенту вне зависимости от ведомственной ответственности за эту услугу. Иначе говоря, гражданин или экономический субъект получает необходимую ему услугу через единый правительственный портал, а не через какое-то конкретное государственное агентство или ряд агентств [32].
Осуществление функций государственного управления в форме услуг, оказываемых гражданам и иным субъектам, - один из краеугольных камней концепции «электронного правительства», т.к. «производители, считающие себя производителями услуг, ... имеют очевидные преимущества в конкуренции» [24].
Клиентоориентированность государственных услуг означает внутреннюю и внешнюю направленность на клиента или заказчика, гибкий подход к оказанию услуг, учет удовлетворенности потребителя услугой.
Формирование «электронного правительства» невозможно без соответствующего перепроектирования государственных управленческих процессов. Поэтому, рассматривая взаимоотношения граждан с органами исполнительной власти через понятие «услуга», к изменению процессов государственной сферы, может быть, применим основополагающий принцип стандартов серии ИСО 9000 - процессный подход [61] - представление деятельности в виде взаимосвязанных процессов. Переход от структурно-функциональной организации деятельности в органах исполнительной власти к системе основанной на процессно-горизонтальной интеграции функционально-вертикальных структур предполагает реинжиниринг административных процессов. Основной идеей, которого является переход к ориентации не на функции, а на процесс производства услуг при активном использовании в управлении ИКТ.
Реинжиниринг административных процессов обеспечит: повышение качества государственных услуг; постоянный рост эффективности деятельности органов власти; развитие современной информационно - коммуникационной инфраструктуры городских организаций; развитие электронной коммерции; открытость административных процессов для граждан; обратную связь между населением и органами государственной власти. постоянное улучшение социально-экономической ситуации в стране, регионе, городе; создание новых условий развития правового и политического самосознания граждан и максимальной реализации их личностного потенциала.
Анализ применимости задаваемого и предлагаемого способов разработки к созданию информационной системы «одно окно» на основании оценки их рисков
На первом этапе выполнения социально-ориентированного проекта нами была определена проблемная среда, а именно: неэффективность информационного взаимодействия между органами исполнительной власти города, городскими организациями и территориальными подразделениями федеральных органов исполнительной власти при подготовке документа для заявителя; непроработанность порядка, взаиморасчетов между органами исполнительной власти (если документ выдается на возмездной основе); отсутствие координации межотраслевого взаимодействия-по подготовке запрашиваемых документов.между государственными учреждениями; обособленность друг от друга ведомственных ИС, созданных в разное время, имеющих различную функциональность и базирующихся на различных аппаратных и программных платформах; отсутствие нормативно-правовой базы, регламентирующей применение электронно-цифровой подписи.
Поскольку нормализации проблемной среды потребует значительных изменений в нерациональной, громоздкой системе подготовки и согласования документов, закрепленной законодательством Российской Федерации и города Москвы, то нами было произведено исследование возможности выполнения проекта в данных условиях, которое заключалось в сопоставление потенциальных рисков двух способов разработки: принятого (по ГОСТ 34.601-90) и функционально-итерационного.
Оценка риска была проведена по методике FMECA, позволяющей проанализировать потенциальные дефекты (риски), их причины и последствия, оценить вероятность их появления и необнаружения, принять меры для их устранения или снижения вероятности и ущерба от их появления [2].
Стандартная методика FMECA-процесса включает следующие шаги: 1. идентификация потенциальных рисковых событий, их последствий и причин; 2. определение для каждого последствия риска ранга коэффициента значимости S — экспертно выставляемый коэффициент, соответствующий значимости данного риска по его возможным последствиям; 3. определение для- каждой потенциальной причины ранга коэффициента возникновения О - экспертно выставляемый коэффициент, соответствующий вероятности возникновения причины данного риска;. 4. определение для каждого рискового события; ранга коэффициента обнаружения D - экспертно выставляемый коэффициент, соответствующий вероятности обнаружения риска в ходе процесса; 5. расчет обобщенного коэффициента критичности (ОКК) на основании! экспертных оценок Sj О; D, по формуле: OKK=S G D 6. сравнение полученного ОКК с допустимой критической границей (ОККкг) в пределах 80-125; 7. разработка корректирующих мероприятий по снижению расчетного показателя ОКК для рисков, у которых значение ОКК ОККкг.
Приводимые в стандартной методике шкалы экспертных оценок коэффициентов специализированы под оценку рисков конструкторских и технологических объектов (продуктов/процессов) в машиностроении. В виду специфики социально-ориентированных проектов нами была произведена адаптация методики FMECA в; соответствии с терминологией предметной области, которая заключалась в определение критериев и ранга коэффициентов S,OHD.
Для машиностроительных отраслей уровень критической границы традиционно задается в пределах 80-125 получается, что верхняя граница ОККкг в первом приближении равна произведению коэффициентов с рангом 5.
На основании данного предположения нами были определены критерии коэффициентов S, О и D соответствующих данному рангу:
критерий коэффициента значимости S = 5 был установлен, как «изменения функционала от 10% - 20%» или «увеличение стоимости от 6% -10%» или «отставание по срокам от 6% -10%» или «незначительное снижение качества», т.к. заказчик счел данный уровень ущерба приемлемым потому, что неизбежное изменение законодательной базы внесет дополнительные требования в запланированную бизнес-логику системы;
критерий вероятности возникновения риска 0= 5 был определен, как «Умеренная: будет наблюдаться несколько раз за время жизненного цикла ИС» в пределах 16% - 20%, т.к. предполагалось, что количество изменений нормативных актов регламентирующих режим «одного окна» будет более одного за время жизненного цикла проекта;
критерий коэффициента обнаружения D = 5 был определен, как «Умеренная вероятность обнаружения. Разработчики следят за информацией о подготовке и согласовании нормативных актов, вносящих изменения в действующее законодательство, участвуют в процессе согласования», т.к. предполагалось, что за время согласования и утверждения нормативного акта можно предпринять действия по подготовке и внесению изменений в разработанные подсистемы ИС.
Исходя из найденных критериев коэффициентов S, О и D соответствующих рангу 5, нами были определены критерии для оставшихся значений (см. таблицы 1-3).
Коэффициент значимости S был декомпозирован на четыре составляющих: стоимость, время, качество (три основных показателя любого процесса) и полнота реализации функционала. По нашему мнению, оценка значимости последствий рисковых событий по данным составляющим коэффициента S позволяет более детально оценивать степень ущерба.
Эволюция методики планирования при переходе к функционально-итерационным проектам
Итеративный жизненный цикл, структурируя проект под достижение предсказуемых и предвидимых целей первоочередных задач, опускает связанную с рисками необходимость планирования работ, выходящих за рамки текущего круга задач. Таким образом, адаптивность итерационных проектов, которая подразумевает «подгонку» под изменяющиеся цели, исключает характерное для «водопадного» стиля планирование в начале проекта всех необходимых работ. Такие планы трудно поддерживать, они быстро устаревают, в них пытаются предсказать будущее, а наряду с главными (обобщенными) контрольными точками, используют множество мелких и детальных.
Следует отметить, что такое снижение рисков проекта обусловлено возможностью более эффективного управления работами по достижению функционально-значимых и первоочередных целей итерации. При этом способ управления проектными работами остается инвариантным, который осуществляется по классическому PDCA-циклу (от англ. Plan-Do-Check-Act). Эта инвариантность позволяет воспользоваться для реализации функционально-итерационного проекта опытом и методикой организации работ классического итеративного проекта, согласно которым при планировании разрабатываются два вида планов: общий план — крупноблочный план проекта с описанием ключевых вех; план итерации - детальный план конкретной итерации. Методика планирования функционально-итерационного проекта состоит из следующих операций: разработка структурной декомпозиции продукта (см. раздел 2.4); определение количества итераций проекта; определение целей, задач и контрольных точек итераций; определение количества этапов каждой итерации; составление плана проекта; разработка плана итерации. План проекта включает следующие основные разделы: Календарный план-график; План распределение ресурсов; Бюджетный план; План управления качеством; План управления рисками; Рабочий план; N План управления.
Процесс планирования состоит из процедур: планирования целей - разработка постановки задачи (проектное обоснование, основные этапы и цели проекта); декомпозиции целей - декомпозиция этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля; определения пакетов работ проекта - составление перечня операций, из которых состоит выполнение различных этапов проекта; оценки длительности пакета работ - оценка временных интервалов необходимых для завершения отдельных операций; определения ресурсов проекта - определение общего количества ресурсов всех видов (людей, оборудования, материалов), которые могут быть использованы при выполнении проекта; назначения ресурсов - определение ресурсов, необходимых для выполнения отдельных пакетов работ проекта; . выбора поставщиков - оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов; оценки стоимости — определение составляющих стоимостей пакетов работ проекта; составления расписания выполнения работ — определение последовательности выполнения пакетов работ проекта и распределения во времени потребностей в ресурсах и затрат с; учетом наложенных ограничений и взаимосвязей; оценки бюджета — приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам); определения критериев успеха - разработка критериев оценки исполнения проекта.
Работы, необходимые для выполнения каждого? этапа проекта; определяются при помощи декомпозиции; продукта проекта, получившего, название пооперационного перечня работ (ПИР, от англ. - work breakdown structure).
Работа - это непрерывное физическое или умственное усилие, направленное на преодоление препятствий и достижение целей или результатов, как специфическая задача, обязанность, функция или задание. Работа часто является частью фазы или другой, большей по объему работы, чем-то производимым или выполняемым в результате усилия или применения навыков (квалификации) [79].
ППР - иерархическая декомпозиция и организация работ (задач, подзадач, действий), выполняемых командой,проекта, необходимых для удовлетворения, целей проекта [1]. Цели ГШР: обеспечение планирования всех необходимых работ проекта; обеспечение отсутствия ненужных (лишних) работ, не связанных с реализацией проекта.
Методика функционально-итерационной разработки информационной системы
Концепция содержит список целей и требований, которые должны быть достигнуты в проекте и основные функциональные возможности разрабатываемой системы [33].
Концепция разрабатывается на одноименном этапе фазы Начало (Рис. 8). По мере изменения понимания требований и архитектуры, планов и технологии концепция может изменяться и дополняться, но должна быть полностью готова к начальным этапам фазы Конструирование.
Содержание Концепции на ИС может меняться в зависимости от требований проекта, но в целом соответствует следующей структуре:
1. Введение.
2. Цели и задачи. Цель выражает некоторое желаемое состояние, которое требуется достичь, либо тенденцию, которой надлежит следовать. Она формулируется в форме императива (приказа). В качестве целей определяются и конкретизируются следующие показатели: полезность производимой информации; надежность; доступность; своевременность получаемой информации; экономическая эффективность; безопасность; управляемость; контролируемость ПО. 3. Функциональные требования к системе. 4. Описание объекта автоматизации, которое включает: обоснование выделяемых подсистем, их перечень и назначение; перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания; схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы. 5. Предложения по созданию системы. 6. Требования к информационной безопасности. 7. Выводы и предложения.
Разработка ТЭО проекта ТЭО предназначено для обоснования производственно-хозяйственной необходимости и технико-экономической целесообразности создания или развития ИС.
ТЭО описывает экономическую ценность продукта для заказчика, выражая ее в количественных единицах. ТЭО — это инструмент для получения адекватного финансирования проекта, в котором обосновывается функциональная структура системы и этапность ее реализации, методы решения и обоснование выбора оборудования и технологий.
ТЭО разрабатывается в соответствии со стандартом ГОСТ 24.202-80 -Требования к содержанию документа «Технико-экономическое обоснование создания АСУ». Недостатком данного стандарта-является то, что он регламентирует только общую структуру документа, но не его содержательную часть.
Разработка ТЗ на систему
ТЗ - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
В соответствии с функционально-итерационным принципом реализации проекта разрабатывается два типа технических заданий: общее ТЗ на систему; частное ТЗ (ЧТЗ) на каждую функциональную подсистему.
Если в общем ТЗ описывается модульная структура системы и основные функциональные требования каждой подсистемы, то в частные ТЗ включаются более детальные требования к каждой подсистеме и ее функциональным компонентам. Такая структура проектной документации позволяет учитывать риски по изменению функциональных требований и упрощает поддержку документации в актуальном состоянии. ЧТЗ разрабатывается на этапе «Техническое задание» фазы Проектирование.
Разработка ТЗ включает в себя решение следующих задач: установка общей цели создания ИС, определение конечного состава подсистем и функциональных задач; установка общих требований к проектируемой системе; разработка и обоснование требований, предъявляемых к подсистемам;
разработка и обоснование требований, предъявляемых к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
определение перечня задач для создания системы; ТЗ разрабатывается в соответствии с требованиями стандарта ГОСТ 34.602-89 - «Техническое задание на создание автоматизированной системы». Фаза Начало завершается контрольной точкой «Цели системы», в которой анализируется степень достижения поставленных целей. В контрольной точке должны быть: утверждена Концепция; определена функциональная структура разрабатываемой системы (см. раздел 2.4 - 2.5); разработан План проекта и план первой итерации (см. раздел 3.2); утверждено ТЭО; утверждено ТЗ на систему. Цели фазы Проектирование разработать базу данных моделей существующих процессов «как есть»; разработать техническую архитектуру системы; разработать ЧТЗ на подсистему; разработать ТП на систему; разработать прототип функциональной подсистемы.
