Один из важнейших компонентов любой информационно-управляющей системы – программное обеспечение. В большинстве случаев именно от его качества зависит эффективность автоматизации управления объектами, системами или процессами [1,2,3,4]. Активная разработка коммерческого программного обеспечения началась ещё в 80-е годы прошлого века. Но, до настоящего времени, процесс создания программного обеспечения (ПО) сложно назвать оптимальным. И этому есть множество причин: технологических, организационных и других. Как показала практика, в своём развитии разработка программного обеспечения проходит те же стадии, которые в своё время проходила разработка промышленной продукции.

На начальном этапе развития программирование, в том числе коммерческое, было, практически, искусством, в котором каждый разработчик кустарным способом создавал продукт, всецело от него зависящий. Впоследствии, с появлением систем программирования, продукт начал обосабливаться от производителя, появилась коллективная разработка. По аналогии с промышленностью, эту стадию можно назвать уровнем мануфактурного производства. В настоящее время, с дальнейшим развитием подходов и систем разработки, рассуждая логически, должна наступить эпоха промышленного программирования, когда каждый разработчик производит только свою программу или функцию (библиотеку), не вдаваясь: зачем и кому она нужна. Должна наступить, но пока не наступила… Почему?

Причин много. Это и несовершенство организационных основ процесса разработки [5,6,7], и субъективные факторы использования средств автоматизации [8] и другие. Одна из существенных причин, на наш взгляд, кроется именно в организации процесса разработки программ. Отсутствие чёткого регламента разработки, её этапности с контролем на каждом этапе, слабая автоматизация этого процесса приводит к парадоксальной ситуации: программный продукт до сих пор продолжает зависеть от своего создателя. В результате, при возникновении необходимости, сторонний разработчик часто просто не может доработать продукт, сделанный до него. Иногда программисту проще написать новую программу, чем доработать существующую. Даже при наличии полноценной конструкторской документации. Это парадокс: любой слесарь со средним образованием может изготовить по чертежу гайку М8, которая навернётся на любой болт с метрической резьбой М8, а программист с высшим образованием – не может по чужой документации доработать программу.

Справедливости ради стоит отметить, что эта проблема существенно продвинулась в решении в части разработки программных средств общего назначения. А вот в разработке прикладного ПО, где процесс существенно более творческий и разнообразный, пока всё остаётся на уровне «мануфактуры». С одной стороны, оправдание этому есть – разработка отдельных задач действительно, подчастую, является уникальным разовым процессом. Но это только при разработке автономных узкоспециализированных задач. А вот при разработке распределённых расчётно-моделирующих комплексов или систем поддержки принятия решений объективно необходимо переходить от «ремесла» к технологиям. А именно это и есть тенденция развития современного ПО – от отдельных задач к системам [9,10,11]. Но эта тенденция пока не подкрепляется использованием соответствующих технологий. Результат – повышенные затраты времени и финансов, дублирование работ.

Но проблема не безнадёжна, пути решения её есть. Как показывает личный опыт автора – они лежат в области грамотной организации труда всех категорий разработчиков. Как за счёт использования структурных подходов к работе на основе стандартов управления проектами PMBoK (Project Management Body of Knowledge), ISO 21500 и реализующей их положения методологии организации разработки, такой, например, как RUP (Rational Unifield Process), так и использования специализированного инструментария автоматизации управления разработкой, например VSS (Microsoft Visual SourceSafe), дальнейшего развития этой системы – TFS (Team Foundation Server) или других систем и веб-приложений для управления проектами и задачами: Jira, Gemini, Savana, Redmine, Trac, TaskJuggler и т.п.

Системы типа TFS предназначены для совместной распределённой работы над проектами по созданию компонентов программного обеспечения. TFS представляет собой комплексное решение, реализующее [12]:

- систему управления версиями;

- сбор данных и построение отчётов;

- отслеживание изменений и статуса проекта.

Работа с TFS организована по принципу трёхуровневой архитектуры: клиентский уровень, прикладной уровень и уровень данных (рисунок 1).

Рисунок 1. Общая структура системы TFS

Клиентский уровень включает следующие компоненты:

- объектная модель TFS, представляющая собой открытый API, используемый для взаимодействия с TFS;

- компоненты VSIP (Visual Studio Industry Partners), инструментальные средства, надстройки и языки программирования сторонних производителей для Visual Studio.

- компоненты интеграции с Microsoft Office, которые включают ряд надстроек Microsoft Office Excel и Microsoft Office Project, обеспечивающих возможность запрашивать и обновлять рабочие элементы в базе данных TFS Work Item Tracking;

- инструментальные средства командной строки;

- инфраструктура политик регистрации изменений файла в системе контроля версий.

Клиентский уровень используется для создания и управления проектами, а также для доступа к хранимым и управляемым элементам проекта.

Прикладной уровень (уровень приложений) предоставляет собой web-сервисы ASP.NET, с которыми взаимодействует клиентский уровень. Они сгруппированы в следующие наборы:

- сервисы обработки данных Team Foundation Data Services;

- сервисы интегрирования Team Foundation Integration Services.

Прикладной уровень включает в себя web-портал Team Project Portal (портал командного проекта), который используется в роли центра взаимодействия проектов, управляемых TFS. В состав прикладных сервисов входят средства контроля версий TFVC (Team Foundation Version Control), серверы сборки и отладки Team Build и Team Load Test Agents и другие.

Уровень данных TFS состоит из следующих компонентов и хранилищ данных:

- компоненты статуса рабочих элементов;

- единый репозиторий на базе SharePoint, содержащий связанную с проектом документацию.

Уровень данных, основывающийся на SQL Server 2005 Standard Edition, обеспечивает сервисы постоянного хранения данных для репозитория документов. Уровень данных и уровень приложений могут существовать на различных физических или виртуальных серверах.

Работа с системой TFS организована интуитивно понятно: создаются проекты (Team Projects), которые делятся на последовательно или параллельно выполняемые работы и связанные наборы задач конечным исполнителям, обладающие определённым набором свойств и статусов. Указанные свойства определяют содержание задачи, исполнителя, сроки реализации и т.п. Связи между задачами и свойствами позволяют контролировать сроки и полноту выполнения этапов проекта.

Как показала практика, TFS обеспечивает автоматизированное выполнение целого ряда важнейших функций управления проектами:

- многократная блокировка файлов для изменения (multiple simultaneous check-outs), позволяющая нескольким пользователям одновременно могут редактировать один и тот же файл;

- отложенное внесение правок (shelving) – сохранение набора изменений, которые необходимо внести в будущем, другие участники проекта будут уведомлены об этих наборах, но если им намеренно не предоставлен доступ, то содержимое будет недоступно для просмотра и изменения;

- ветвление с последующим слиянием (branching and merging);

- урегулирование конфликтов в случае слияния различных «веток»;

- разграничение уровней доступа – независимо для разных файлов и папок

- поддержка версионности документации;

- откаты до предыдущих версий, в том числе по отдельным «веткам» проекта;

- операции подтверждения малых изменений (atomic commits).

Каждая из перечисленных функций, выполняемая в совокупности проекта, существенно упрощает управление разработкой прикладного ПО.

Как показал практический опыт использования TFS при разработке крупных проектов прикладного ПО, данное средство достаточно эффективно обеспечивает автоматизацию:

- постановки задач разработчикам и контроля их выполнения;

- архивации данных о версионности и вносимых в программы изменениях;

- сборки версий (в том числе автоматической, с рассылкой уведомлений) и контроля версионности продукта.

С учётом этого, автоматизация организации процесса разработки обеспечивает существенное повышение его эффективности.

Конечно, TFS не является спасением от всех бед в области промышленной разработки ПО. Собственно, при наличии грамотного руководства и отлаженного процесса организации труда в организации, все функции управления процессом разработки могут быть реализованы и в неавтоматизированном режиме [13,14,15]. То же самое можно сказать о небольших уникальных проектах, разрабатываемых под конкретную задачу в сжатые сроки. Хотя последний случай, всё-таки спорный. Часто быстро разработанный и внедрённый проект приходится дорабатывать в ходе эксплуатации, и тут использование TFS при разработке сильно упростило бы процесс настройки под требования пользователей. А для некоторой «среднестатистической» организации, да ещё и ведущей несколько нетиповых проектов, TFS – серьёзное подспорье в работе в любом случае. Тем более, что данный тип ПО является организационным и его влияние на состояние конечного программного продукта минимально и не противоречит требованиям информационной безопасности  [16,17].

Разумеется, использование TFS в разработке программного обеспечения, не панацея. Всех проблем ни RUP, ни TFS не решит. Но это одна из предпосылок повышения эффективности использования немалого, но пока слабо востребованного интеллектуального потенциала страны и перехода от использования зарубежного ПО к отечественному, что очень актуально в условиях перманентного информационного противоборства в современном постиндустриальном мире [18,19,20].

1. Тиханычев О.В. Автоматизация поддержки принятия решений. Научно-теоретически труд – М.: Эдитус, 2015. – 94 с.
2. Тиханычев О. В. Системы поддержки принятия решений — перспективное направление развития автоматизации управления войсками (силами) // Военная мысль. 2012. № 8. С.45–51.
3. Tikhanychev O.V. Decision-Making Support Systems: Prospects for Troops Control Automation // Military  Thought. Vol. 21 Number 3, 2012, p.74-83.
4. Выпасняк В. И., Тиханычев О. В. Автоматизированные системы управления войсками (силами): тенденции, методы и перспективы развития // Вестник Академии военных наук. 2009. № 4 (29). С.61–68.
5. Тиханычев О. В., Гахов В. Р., Харламов К. В. Информационное обследование — основа создания эффективной АСУ // Сборник трудов ежегодной Всероссийской научной конференции «Современные тенденции развития теории и практики управления в системах специального назначения». М.: ОАО «Системпром», 2013.
6. Тиханычев О.В., Саяпин О.В., Гахов В.Р. Использование современных технологий информационного обследования как фактор эффективности автоматизации управления // Информатизация и связь №6 2013. С.90-93
7. Тиханычев О.В. Общие подходы к обеспечению автоматизированной поддержки принятия решений. – М.: Эдитус, 2014. – 64 с.
8. Тиханычев О. В. Субъективные аспекты применения математического моделирования военных действий в практике работы органов военного управления // Военная мысль. 2011. № 10. С.49–53.
9. Выпасняк В.И., Гуральник А.М., Тиханычев О.В. Система поддержки принятия решений как «виртуальный штаб» // Военная мысль №2 2015, С.23-29.
10. Tikhanychev O.V., Vypasnyak V.I., Guralnik A.M. A Decision-Making Support System as a Virtual HQ // Military Thought. Vol.24 Number 1, 2015, p.129-136.
11. Выпасняк В. И., Тиханычев О. В., Калиновский Д. Б. Моделирование вооруженного противоборства: перспективы развития // Военная мысль. 2009. № 7. С.12–20.
12. Team Foundation Server. Википедия. Свободная энциклопедия. URL: https://ru.wikipedia.org/wiki/Team_Foundation_Server
13. Выпасняк В.И., Гуральник А.М., Тиханычев О.В. Моделирование военных действий – история, состояние, перспективы развития // Военная мысль №7 2014. С.28-37.
14. Иванова. Г.С., Ничушкина Т.Н. Проектирование программного обеспечения. Учебное пособие. М.: МГТУ им. Н.Э. Баумана, 2002. – 74 с.
15. Vypasnyak V.I., Guralnik A.M., Tikhanychev O.V. Combat Simulation: Past, Present and Future // Military  Thought. Vol. 23 Number 3, 2014, p.30-41.
16. Доктрина информационной безопасности Российской Федерации (утверждена Указом Президента РФ № 646 от 5 декабря 2016 г.)
17. О внесении изменений в Федеральный закон “Об информации, информационных технологиях и о защите информации” и статью 14 Федерального закона “О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд. 188-ФЗ от 29.07.2015 года
18. Выпасняк В.И., Тиханычев О.В., Гахов В.Р. Киберугрозы автоматизированным системам управления // Вестник Академии военных наук. 2013. № 1 (42). С.103-109.
19. Тиханычев О. В., Гахов В. Р. «Кибер-войны» как реальная угроза системам государственного управления (по взглядам иностранных специалистов) // Сборник трудов второй МНТК «Компьютерные науки и технологии» (КНиТ-2011). Белгородский ГНИУ, Белгород, 2011 г.
20. Огородников Д.В. Касперский маршрутизирует трафик // Ведомости. 18.08.2016. URL: https://www.ts/technoserv/about/company/press/articles/6820/

Все статьи автора «Oberst»