CC BY
47
УДК 330.123.6. 681.53(89)
АНАЛИЗ ДОГОВОРНЫХ ДОКУМЕНТОВ И ТЕХНИЧЕСКИХ ЗАДАНИЙ ГОСУДАРСТВЕННЫХ КОНТРАКТОВ НА УСЛУГИ РЕАЛИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ
Сергей Владимирович Зуев, аспирант, руководитель группы разработки
«UNISLabs Solutions»
Тел.: (965) 337-61-17, e-mail: [email protected] Алефтина Ивановна Кузнецова, д. э. н., проф., проф. кафедры экономики городского хозяйства и сферы обслуживания Тел.: (915) 318-19-48, e-mail: [email protected] Московский университет им. С. Ю. Витте http://www.muiv.ru Виктор Владимирович Леонтьев, к. ф.-м. н., зав. сектором НИВЦ Тел.: (985) 769-45-24, e-mail: [email protected] МГУ им. Ломоносова http://www.msu.ru
В докладе рассмотрены проблемы определения стоимости государственных контрактов на разработку информационных систем. Рассматриваются вопросы управления и контроля процесса разработки систем, а также проблемы оценки экономической эффективности контрактов со стороны государства.
Ключевые слова: государственные контракты, информационные системы, техническая документация, рентабельность, управление процессом разработки, Agile, COCOMO, трудозатраты.
Один из постулатов развития современной экономической системы - равенство участников рынка в возможности осуществления товароденежных отношений. Наиболее близкие к равенству возможностей процессы возникают при случайных событиях.
Современное государство невозможно представить себе без глобальных электронных информационных систем. Их задача может заключаться как в автоматизации ежедневной деятельности сотрудников государственных организаций, так и в предоставлении ранее невозможных инструментов для анализа, учета, сбо- J
ра и обработки информации, принад- чк
лежащей к самым различным предметным областям.
Государственная программа Российской Федерации «Информационное общество (2011-2020 гг.)» определяет в качестве своей цели на период реализации: «получение гражданами и организациями преимуществ от применения информационных и телекоммуникационных технологий за счет обеспе- Н чения равного доступа к информационным ресурсам, развития ^ цифрового контента, применения инновационных технологии, радикального повышения эффективности государственного управления при обеспечении безопасности в информационном обществе» [1].
В связи с этим становится важной интенсивная разработка государственных электронных информационных систем, позволяющих автоматизировать и улучшить качество услуг, осуществляемых государственными предприятиями в сферах здравоохранения, социальных, промышленных сферах и т.д.
Кузнецова
В последние годы соответствующие контракты на реализацию, поддержку и развитие подобных систем предлагаются на конкурсной основе в виде тендеров. Распоряжением правительства от РФ от 2006 г. N 229-Р «общение» государственных заказчиков с конечными исполнителями в добровольном порядке переводится в централизованный источник в сети Интернет [17].
Тендер представляет собой конкурс, в котором производители услуг соревнуются друг с другом за право получить заказ на исполнение. Сторона-закупщик информирует рынок о том, что ей требуется определенный товар или услуга, выдвигает требования, которым должна соответствовать сторона-исполнитель, и все те, кто производят данные товары/услуги и соответствуют выдвинутым требованиям, имеют законное право послать свою заявку на тендер, поучаствовать в конкурсе и выиграть его. Типовой тендер содержит в открытом доступе регламентированную конкурсную документацию в случае проектов, связанных с проектированием, разработкой и внедрением информационных систем, техническое задание на проведение работ.
Инженерные дисциплины и направления, такие как строительство, машиностроение и проч., невозможно представить без десятилетиями разрабатывавшихся и совершенствовавшихся экономических инструментов, позволяющих оценивать, планировать и, в процессе производства, контролировать человеческие и финансовые ресурсы проекта. Очевидно, что и в программной инженерии были разработаны соответствующие инструменты и методологии.
Однако, если мы будем сравнивать строительство и разработку ПО, то в первом случае для успешной реализации проекта необходимо собрать достаточный объем информации - свойства грунта, архитектурные решения, используемые материалы и проч. В случае IT-проекта возникает множество вероятностных факторов, которые невозможно максимально точно оценить на начальных этапах. В период сбора информации о проекте, моделирования бизнес-процессов, обоснования и проектирования архитектуры системы возникают вопросы и уточнения, иной раз кардинально меняющие общую картину. Это создает ситуацию, когда невозможно определить материальные затраты, трудовые ресурсы и время для успешной реализации проекта.
Одной из первых попыток систематизации процесса разработки является предложенная в 1956 г. Ошибка! Источник ссылки не найден. методология последовательной, «итеративной» разработки. В ней проект разбивался на последовательные фазы, каждая из которых начиналась только после успешного завершения предыдущей. В 1970 г. (Royce, Managing the Development of Large Software Systems, 1970) Уинстон Ройс предложил усовершенствованный вариант, известный как «водопадная модель». В этой методологии уже ярко постулировались следующие этапы:
1. предварительное определения требований проекта;
2. проектирование;
3. реализация (конструирование и воплощение в программном коде);
4. документирование;
5. отладка;
6. установка готового ПО заказчику;
7. поддержка существующей системы.
Программные проекты теперь подвергались количественным оценкам. Это значительно упрощало организационные задачи при разработке и внедрении крупных систем. Однако спустя некоторое время стало ясно, что «водопадная модель» не идеальна в условиях перманентно изменяющихся требований, мобильности программного кода, необходимости краткосрочных мгновенных оценок трудозатрат и проч. В качестве па-
нацеи были разработаны и в настоящее время развиваются так называемые «гибкие» (Agile) методологии, которые будут рассмотрены позднее.
Государственные контракты предлагают на реализацию проекты информационных систем. В связи с этим важными становятся вопросы о предпроектной оценке объема работы, который необходимо проделать, и об оценке первичного состава «ядра» команды непосредственных исполнителей, которые будут воплощать проект в жизнь.
Рассмотрим ситуацию со стороны того, что предлагает конкурсная документация. Для статистического исследования были взяты 20 завершенных государственных контрактов на разработку информационных систем. Брался период 2011-2012 гг., при этом рассматривался бюджет проектов от 5 до 50 млн рублей. Конечный программный продукт должен был использоваться в различных отраслях: социальной, медицинской, страховой, индустриальной.
Выборка показывает, что ни один из представленных конкурсных документов не содержит полной информации о разрабатываемых системах. Отсутствует упоминание о предпроектной подготовке. При этом в конкурсной документации часто осуществляется ссылка на ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», однако, предоставленная информация не удовлетворяет этим требованиям.
Технические задания представляют собой общий перечень реализуемого функционала по модулям, но никоим образом не проясняют трудоемкости каждого этапа работ и не содержат в себе подобной информации, определенной со стороны заказчика.
С другой стороны, конкурсная документация содержит некоторый набор критериев, по которому будет проходить отбор кандидатов на реализацию контракта. Итоговое решение определяется по набору взвешенных параметров, так или иначе характеризующих проект и потенциального исполнителя. Данная методика регламентирована постановлением Правительства РФ «Об утверждении Правил оценки заявок на участие в конкурсе на право заключить государственный или муниципальный контракт на поставки товаров, выполнение работ, оказание услуг для государственных или муниципальных нужд».
В таблице 1 в качестве примера приведен общий набор характеристик исполнителя из проекта разработки областной медицинской информационной системы.
Видно, что данная методика оценивает навыки группы разработчиков в смежной предметной области, хотя непонятно, как оценивать «расходы на техническое обслуживание товара» без предварительного проектирования. Аналогично непонятно, как определять срок выполнения работ.
Важнейшей задачей, возникающей перед началом реализации программного проекта, является оценка трудовых и временных затрат. В данном случае корректная оценка непосредственно влияет на бюджет проекта, что позволяет исключить ситуации либо недостаточного финансирования проекта, либо его чрезмерного финансирования.
Вопрос оценки трудозатрат стал актуальным достаточно давно. Фредерик Брукс еще в 1975 году в своей монографии «Мифический человек-месяц» (Ф., 2012) предложил набор долей в процентах, пользуясь которыми можно приблизительно оценить длительность отдельных фаз проекта, зная его определенную кем-либо заранее длительность:
- 33% - планирование;
- 17% - отладка;
- 25% - тестирование компонентов и предварительное системное тестирование;
- 25% - системное тестирование при наличии все реализованных компонентов.
Очевидно, что невозможно пользоваться данной методикой в том случае, когда необходима некоторая точность при планировании бюджета проекта. Как следствие, в последующем стали разрабатываться новые методики оценки трудоемкости и себестоимости IT-проектов. В 1981 году Барри Боэм (Boehm, 1981) разработал методику СОСОМООшибка! Источник ссылки не найден. (Constructive Cost Model - модель
издержек разработки). Поскольку большинство проектов в индустрии информационных технологий проектируются и развиваются по типовым сценариям, Боэм предложил модель оценки трудозатрат, опирающуюся на статистические выборки некоторого числа параметров, характеризующих реализацию проекта. К 2000 году произошла модификация методики с учетом более широкого взгляда на процесс разработки. Новая версия получила название СОСОМО ІІОшибка! Источник ссылки не найден..
Таблица 1
Критерии оценки госконтракта из выборки
Критерии оценки Балльные оценки критериев (максимально составляет 100%)
1. Цена контракта (руб.) Значимость критерия составляет 35%
2. Качество работ и квалификация участника конкурса Значимость критерия составляет 20% (общее количество баллов не может превышать 100 баллов)
2.1. Предложена и описана методика обследования объекта автоматизации. (максимальное значение показателя составляет 10 баллов)
2.2. Представлена схема комплексной автоматизации, подробно раскрыты методологические подходы к интеграции имеющихся и разрабатываемых систем в рамках работ по созданию регионального фрагмента единой государственной информационной системы здравоохранения области. Описано разделение функциональности и взаимодействие. (максимальное значение показателя составляет 10 баллов)
2.3. Представлены детальные предложения по разработке регламентов информационного обмена в соответствии с требованиями ТЗ для регионального сегмента ЕГИС - Здравоохранения области. (максимальное значение показателя составляет 10 баллов)
2.4. Представлены предложения по разработке нормативного обеспечения создаваемого регионального сегмента ЕГИСЗ, представлено подробное описание и структура проектов нормативных документов. (максимальное значение показателя составляет 25 баллов)
2.5. Предложена и описана методика автоматизированного сбора данных и расчета ключевых показателей эффективности для системы здравоохранения области. (максимальное значение показателя составляет 25 баллов)
2.6. Опыт выполнения аналогичных работ в сфере автоматизации процедур государственного управления в сфере здравоохранения у участника конкурса. (максимальное значение показателя составляет 20 баллов)
3. Срок выполнения работ Единица измерения - день. Значимость критерия составляет 35%
4. Расходы на техническое обслуживание товара Единица измерения - рубль. Значимость критерия составляет 10%
СОСОМО рассматривает процесс разработки IT-проекта, опираясь на взвешенные параметры, оценивающие степень воздействия различных факторов - навыки команды, осведомленность в предметной области, возможности аппаратных средств, сложность проекта и т.п. При этом одним из параметров является объем проекта, оцениваемый в KSLOC (kilo source lines of code - тысячи строк исходного кода). На выходе же получается необходимая для оценки длительности, следовательно, и стоимости величина PM (person-months - человеко-месяцы).
Другим способом оценки является метод функциональных точек (МФТ), разработанный Аланом Альбрехтом в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group - IFPUG), которая опубликовала несколько ревизий методаОшибка! Источник ссылки не найден.. МФТ
основывается на анализе логической модели программного продукта и характеризуется оценкой количества функционала, востребованного и поставляемого заказчику.
Государственные IT-проекты размещаются посредством электронных торгов, соответственно, на момент проведения аукциона находятся в стадии предварительного проектирования и подготовки. СОСОМО II предлагает использование ограниченного числа параметров, влияющих на итоговый результат. Эти параметры можно использовать как критерии для экономической оценки госконтракта перед стадией размещения заказа.
Рассмотрим основную формулу вычисления трудозатрат СОСОМО II (Архипенков, 2009):
ГМ ,4 X SIZE' X "PI ЕМ,
А _ 2 94 1 где: SIZE - размер продукта в KSLOC (тысячах строк исходного кода);
5 ЕМ! - множители трудоемкости; SFj - факторы масштаба; п=7 - для
е = в+0,01 х £ sf. предварительной оценки; n= 17 - для детальной оценки.
Расчет трудоемкости в данном случае можно разбить на три этапа:
1. Определение объема программного продукта в тысячах строк исходного кода.
Очевидно, что до непосредственной реализации информационной системы невозможно дать точно оценку объема ПО. С другой стороны, здесь возможны два варианта:
• использование исторического статистического материала. Большинство создаваемых информационных систем носит достаточно типовой характер в архитектурном и функциональном плане. При наличии информации об объемах подобных систем можно получить некоторую среднюю величину, пригодную для оценки текущего проекта;
• более качественную оценку на данном этапе может дать вышеуказанный метод функциональных точек. МФТ позволяет оценивать единицу функционала ПО в количестве строк кода, основываясь на статистике по отрасли (Function Point Programming Langua-ges Table, 2005).
2. Определение величин множителей трудоемкости.
Для предварительной оценки проекта СОСОМО II предлагает семь множителей трудоемкости (Архипенков, 2009):
• PERS - квалификация персонала;
• RCPX - сложность и надежность продукта;
• RUSE - разработка для повторного использования;
• PDIF - сложность платформы разработки;
• PREX - опыт персонала;
• FCIL 0 оборудование;
• SCED 0 сжатие расписания.
Пользуясь источником (Barry Boehm, 2000), видим, что при недостаточной квалификации персонала как непосредственно в разработке, анализе, так и в использовании соответствующего инструментария, трудоемкость проекта возрастает почти в 4 раза по сравнению с нормальными условиями.
3. Определение факторов масштаба:
• PREC 0 прецедентность, наличие опыт аналогичных разработок;.
• FLEX 0 гибкость процесса разработки;
• RESL 0 архитектура и разрешение рисков;
• TEAM 0 сработанность команды;
• PMAT 0 зрелость процессов.
В этом случае СОСОМО II предоставляет разноплановую оценку длительности проекта. Однако стоит учитывать, что многие из вышеперечисленных критериев имеют
смысл и применимы непосредственно к команде разработчиков. В тот момент, когда государственный заказ на разработку информационной системы поступает в реестр аукционов, информация о конечном исполнителе неизвестна. В этом случае определение трудозатрат и, соответственно, стоимости контракта придется проводить по одному из двух сценариев:
• Использование упрощенной методологии СОСОМО II, в которой число строк исходного кода оценивается по средним отраслевым значениям. Множители трудоемкости и факторы масштаба выбираются по номинальным значениям.
• Обязательный этап предпроектной подготовки, возможно, выполненный в виде отдельного тендера. При этом оценку проекта и разработку необходимой технической документации выполняет сторонний, не связанный с исполнителем, подрядчик. На этом этапе возможно подготовить подробное техническое задание, а также собрать более полную отраслевую статистику для проектов текущей предметной области и на основе нее провести качественный анализ трудозатрат.
Проектирование и программирование являются центральными процессами в разработке программного обеспечения. Однако в государственных проектах с жестко определенным бюджетом, помимо чисто технических задач, возникают задачи экономического и организационного характеров. Вышеуказанные методики предпроектной оценки наглядно показывают зависимость конечной стоимости проекта от множества различных факторов. С другой стороны, труд 1Т-специалиста - наемный труд. Государство, в свою очередь, предусматривает трудовое законодательство для регулирования взаимоотношений наемных трудящихся и их работодателей. Отсюда следует, что бюджет проекта должен быть определен с учетом затрат на содержание наемной рабочей силы с учетом всех налогов и выплат, требуемых законодательством РФ.
Попробуем определить состав команды для разработки абстрактной информационной системы. Ф. Брукс приводил примерный состав участников группы разработки. В качестве примера на этой основе, с учетом изменений, произошедших в индустрии программной разработки, получим следующее:
• Специалист по тестированию. Разработка информационной системы - конвейерный процесс. Внесенные изменения в систему обязаны быть протестированными на предмет реализации поставленных разработчикам задач, а также отсутствия регрессивного влияния на систему в целом.
• Бизнес-аналитик. Наличие в проекте человека - специалиста в текущей предметной области - является огромным плюсом для всего процесса разработки в целом. В задачи бизнес-аналитика входит принятие требований заказчика и изложение их в виде понятных программистам моделей.
• Дизайнер пользовательского интерфейса. Комфорт работы, скорость вхождения новых пользователей в систему, среднее время (число шагов) для выполнения стандартных задач целиком и полностью зависят от дизайна интерфейса.
• Архитектор базы данных. Основа современных информационных систем -сбор и обработка информации. Системы реляционных баз данных (СУБД) предоставляют хранилище и удобный инструментарий для выполнения данных задач. Типовые системы строятся вокруг модели базы данных (какая-нибудь ссылка), поэтому качественное проектирование и возможность оперативного расширения БД очень важно.
• Программист бизнес-логики. Занимается непосредственно реализацией технического задания и постановок задач от заказчика в виде программного кода.
• Руководитель группы разработки. Является «дирижером» процесса разработки системы, управляет персоналом, определяет стратегию прогресса и развития ИС.
• Руководитель проекта. Каждый участник команды занимается работой согласно своей технической специальности. Однако, как уже было сказано, 1Т-проект содержит в себе задачи и экономического, и юридического характеров. В команде должен
быть человек, занимающийся внешними организационными задачами, а также определяющий глобальные стратегии развития проекта.
Средняя заработная (СЗ) плата программиста в Москве на момент написания статьи составляла 73 000 рублей [10]. Организация в данном случае, пользуясь законодательством РФ, тратит на одного специалиста следующую сумму:
ОЗ = СЗ + СЗ * 0.30 = 73 000 + 73 000 * 0.30 = 94 900 рублей, где:
• ОЗ - общие затраты на единицу персонала,
• 0.30 - социальные выплаты в ПФР в виде налога на трудовую единицу в объеме 30% от заработной платы (актуально на 2013 г.).
Отсюда получается, что для определенной выше команды из 8 человек затраты организации в месяц составят 94 900 * 8 = 759 200 рублей. Предварительная оценка выборки государственных тендеров показывает, что среднее время заключения контракта составляет 1 год. В этом случае только кадровый зарплатный бюджет проекта должен составлять 9 110 400 рублей.
Этот же проект жестко определяет сроки реализации контракта:
«5.1. Работы должны быть произведены Подрядчиком в срок не более 90 (девяноста) календарных дней с момента заключения настоящего Договора, но не позднее 31 декабря 2012 г.».
В данном случае 90 календарных дней прописаны без учета праздников и выходных. Стандартный рабочий месяц содержит 22 рабочих дня, поэтому расчеты стоит вести с учетом срока в 66 дней.
Стоимость контракта приблизительно составляет 51 000 000 руб. НДС принимаем в размере 18%, что составляет 9 180 000 руб. Итоговая сумма составит 41 820 000 руб., или 13 940 000 руб./месяц. Выше мы определили кадровый бюджет организации на типовую команду из 8 человек - 759 200 руб ./месяц. Без учета возможности привлечения сторонних подрядчиков для исполнения заказа исполнитель в итоге получает прибыль в 13 180 800 руб./месяц.
В данном случае мы не учитываем организационные затраты в виде оплаты электроэнергии, аренды помещения, телекоммуникационных каналов и проч. Экономическая эффективность проекта со стороны исполнителя составляет:
^прибыль 13 180 800 * 3
Еи = -------*100%^^^———*100%= 77%
^затраты 51 000 000
В ситуации, когда срок исполнения контракта ограничен концом года, исполнитель оказывается в ситуации, когда плановую работу, рассчитанную на 1 год, приходится выполнять за значительно более краткие сроки.
Исполнитель может варьировать состав команды разработчиков: например,
увеличить число людей, занятых над проектом. При этом все соотношения остаются теми же самыми, что и при расчете для команды из 8 человек. Экономическая эффективность же будет снижаться (рис. 1).
Анализ контрактов показывает, что экономическая эффективность проектов составляет 60-95% при сроках реализации до
1 года. В таблице 2 приведены показатели эффективности проекта (%) для исполнителя
от численности команды (человек) и сроков рентабельности отраслей экономики РФ в
исполнения контракта (мес.) 2003 г.
Таблица 2
Показатели рентабельности отраслей экономики РФ в 2003 г.
Отрасль экономики Рентабельность капитала, %, в 2003 г.
Вся промышленность 10.8
Электроэнергетика 2.0
Топливная промышленность 17.5
Металлургический комплекс 26.6
Машиностроение и металлообработка 8.5
Химическая и нефтехимическая 9.9
Лесная, деревообрабатывающая и целлюлоз- 7.5
но-бумажная
Легкая промышленность -5.8
Пищевая промышленность 19.3
Другие отрасли промышленности
Торговля 14.8
Строительство 10.4
Транспорт 6.0
Связь 34.5
Сельское хозяйство 3
Таблица 2, взятая из (И., 2003) показывает рентабельность экономических отраслей в РФ в 2003 г. Видно, что разработка государственных информационных систем необычайно рентабельна по сравнению с экономикой в целом. С другой стороны, контракты явно не определяют необходимость предпроектной подготовки (проектирования, тестирования и документирования системы). В большинстве случаев при предоставлении конкурсной документации для начала тендера данная подготовка не ведется. Соответственно, данная процедура также ляжет на плечи исполнителя в указанный срок - 66 дней, что представляется малореальным.
Как показал обзор государственных заказов на разработку информационных систем, предварительная оценка проектов не проводится. Отсюда непонятно первоначальное формирование суммы бюджета и непонятен установленный срок выполнения контракта.
Без установления первоначальных требований к проекту, без наличия сформулированного подробного технического задания проект будет развиваться в хаотическом порядке. Поскольку первоочередная цель любой коммерческой компании - это прибыль, в условиях неоправданно заниженного срока контракта реализация может вестись за вычетом подготовительных и сопутствующих процессу разработки работ. Весьма распространенной практикой является игнорирование фаз анализа системных требований, проектирования, тестирования и документирования продукта. Отсутствие проектирования ведет к решению разработчиками задач по факту поступления. При этом, если не проводится глобальное и всестороннее тестирование, может возникнуть ситуация регрессивного влияния новых изменений на уже реализованный функционал.
Техническое документирование архитектуры системы, алгоритмов реализации поставленных задач, программных интерфейсов и проч. позволяет представить целостную картину актуального состояния системы. Помимо этого, в командах с большим количеством разработчиков актуальная документация способствует повторному использованию кода. При следовании общих концепций разработки данной системы и обязательном документировании ее функционала снижается порог вхождения для новых разработчиков - уменьшается зависимость развития проекта от конкретных исполнителей.
С того момента, как разработка программного обеспечения перестала быть уделом лабораторных экспериментов и превратилась в полноценную отрасль, происходит
постоянное развитие организационном и управленческой моделей и методологии. Группа разработчиков должна выдерживать сроки, выходить на плановые показатели и выдавать в итоге готовый качественный продукт.
В 1970 Уинстон Ройс предложил (Royce, Managing the Development of Large Software Systems, 1970) модель «водопада» - последовательный процесс разработки программного обеспечения с этапами определения требований, проектирования, разработки, внедрения и последующей поддержки. Очевидно, что любой комплексный инженерный процесс рационально разбить на последовательные этапы, каждый из которых будет предоставлять функционально закон-
ченный набор документации (проектной, технической и т. п.), либо какое-то состояние продукта. Данная модель находит отклик и сегодня, но на протяжении длительного времени ее эксплуатации были выяснены многие недостатки, в том числе - отсутствие гиб-Рис. 2. Модель «водопада» кости развития процесса
производства ПО вследствие отсутствия обратных связей между этапами «водопада». Рисунок 2, взятый из (Кулямин, Компонентный подход в программировании, 2006) схематично показывает этапы жизненного цикла проекта модели «водопада».
В условиях жестко поставленных сроков, а также отсутствия подробного и проработанного технического задания государственные IT-проекты изначально находятся в условиях неопределенности. Неопределенности возникают в том случае, если заказчик (государственная организация) в силу тех или иных обстоятельств 0 обновление, смена законодательства - меняет требования к продукту на протяжении периода разработки. Модель «водопада» определенно не может быть применена в подобных условиях.
Подобные случаи нашли свое отражение при разработке группы новых методологий, получивших общее название «гибкие методологии разработки» (англ. - Agile software development). Отличительной чертой нового подхода была попытка минимизации рисков путем разбиения процесса разработки ПО на короткие итерации, каждая из которых включала в себя те же самые процессы проектирования, разработки, тестирования и документирования, как и в случае «водопадного» подхода. Отдельная, единичная итерация не приводит к появлению законченного продукта, однако позволяет корректировать требования к проекту. В результате итерации должен получиться функциональный «срез» конечной системы, который удобно показывать заказчику и который дает возможность проводить тестирование и внедрение систем с ограниченным функционалом на протяжении периода разработки.
Следует отметить один момент: «гибкие» методологии разработки подчиняются единому набору неформальных правил «Agile-манифесту» [12]. Данный документ формулирует одно из правил, которое звучит как: «Работающий продукт важнее исчерпывающей документации».
Важно понимать, где хороши итеративные Agile-принципы - это увеличивает степень готовности процесса разработки ПО к изменениям. С другой стороны, отсутствие исчерпывающей документации снижает мобильность исходного кода проекта. Любая коммерческая организация на протяжении выполнения контракта несет кадровые
риски - разработчики, аналитики, проектировщики могут уволиться. В этом случае важно минимизировать затраты на включение новых людей в процесс разработки. Очевидно, что чем выше количество и качество документации, а также отсутствие ситуации, когда определенным направлением в проекте занимался один человек, единичный «носитель» информации в своей предметной области, тем лучше. При данных положительных факторах порог вхождения новых сотрудников будет ниже. Соответственно, снижаются трудозатраты проекта.
При невозможности легкой замены сотрудников, занимающихся разработкой системы, возникает ситуация, когда конечный проект в итоге фактически оказывается интеллектуальной собственностью организации, которая его изначально разрабатывала. Это дает возможность манипулирования заказчика со стороны исполнителя.
Выводы:
1. Государственные заказчики не представляют полную техническую документацию для реализации проектов информационных систем. При этом отсутствует какая-либо предпроектная экспертиза, позволяющая обосновать выставленную цену контракта.
2. Не существует методик контроля исполнителя со стороны государственных заказчиков в процессе реализации контракта. Исполнитель становится неформальным хозяином получившейся системы.
3. Рентабельность проекта для исполнителя находится в диапазоне 60-95%. При этом невозможно рассчитать экономическую эффективность проекта со стороны госза-казчика.
Литература
1. Государственная программа Российской Федерации «Информационное общество (2011
- 2020 годы)». Российская Федерация, Министерство связи и массовых коммуникации. 2010.
2. Symposium on advanced programming methods for digital computers. Navy Mathematical Computing Advisory Panel.
3. Managing the Development of Large Software Systems 1970Proceedings of IEEE WESCON261-9
4. Брукс Ф. Мифический человеко-месяц, или как создаются программные системы. Изд-во: Символ-Плюс, 2006. - С. 304
5. Software Engineering Economics Englewood Cliffs. NJ: Prentice-Hall, 1981. ISBN 0-13822122-7.
6. Software Cost Estimation with COCOMO II (with CD-ROM). Englewood Cliffs. NJ: Prentice-Hall, 2000. ISBN 0-13-026692-2.
7. Function Point Counting Practices Manual, Release 4.2IFPUG2004.
8. Архипенков С. Лекции по управлению программными проектами. М, 2009. [Электронный ресурс]. URL: http://www.arkhipenkov.ru/resources/sw_project_management.pdf
9. Function Point Programming Languages Table Quantitative Software Management, Inc.2005.
10. http ://rabota.yandex.ru/salary.xml?text=программист&rid=213
11. Николаев И. Рентабельность отраслей экономики РФ. [Электронный ресурс]. URL: http://www.contrtv.ru/common/1045.
12. http://agilemanifesto.org/iso/ru/Agile Manifesto
13. A Discipline of Programming. 1976. ISBN-13: 978-0132158718.
14. Managing the Development of Large Software Systems. 1970. Proceedings of IEEE WESCON 26 (August)1-9.
15. Распоряжение Правительства Российской Федерации от 20 февраля 2006 г. № 229-р «Об официальном сайте Российской Федерации для размещения информации о размещении заказов на поставки товаров, выполнение работ, оказание услуг для федеральных
государственных нужд» (с изм., внесенными распоряжением Правительства РФ от 17.03.2008 № 330-р (ред. от 15.06.2009) .
16. Кулямин В.В.Компонентный подход в программировании. — М.: Интернет-университет информационных технологий, 2006. КБК 978-5-9556-0067-3.
17. Конкурсная документация открытого конкурса на выполнение работ по разработке, внедрению в промышленную эксплуатацию и сопровождению региональной информационной системы предназначенной для автоматизации учреждений системы здравоохранения Брянской области (Электронная медицина). [Электронный ресурс]. ИКЬ: http://zakupki.gov.ru/.
Analysis of Contract Documents and Technical Specifications of Public Contracts for Development of Informational Systems
Alevtina Ivanovna Kuznetsova, Doctor of Economic Sciences , Professor, Professor of Municipal Economy and Service Sector Department, Moscow University after S.Yu. Witte Sergey Vladimirovich Zuyev, Postgraduate, Head of Group of Development of ”UNIS Labs Solutions”, Moscow University after S.Yu. Witte
Viktor Vladimirovich Leontiev, Candidate of Physical and Mathematical Sciences, Head of Sector SRCC MSU after M. V.Lomonosov
This article demonstrates the problems the government contracts value for the development of information systems. The management and controlling of system development process are considered. In addition the problems of evaluating the profitability of contracts by the state are dwelled on.
Keywords: state contracts, information systems, technical documentation, profitability, development process management, Agile, COCOMO, labor expenses.
