Для качественного решения таких проблем на предприятиях используются автоматизированные системы управления (АСУ).

Целью данной статьи является освещение разработанного программного приложения для обеспечения деятельности санатория, в частности разработка автоматизированного рабочего места врача – терапевта.

Актуальность данного программного приложения обуславливается необходимостью:

1. Ведения сбора сведений и оценки результатов оказания медицинской помощи, необходимых для эффективного лечения, профилактики и реабилитации;

2. Сокращения сроков ожидания медицинской помощи за счет управления потоками пациентов, предоставления данных о загрузке врачей, доступности ресурсов в реальном времени;

3. Сокращения затрат на лечебно-профилактический процесс;

4. Повышения оперативности доступа к информации: вся медицинская информация о пациенте, результатах профилактической и лечебно-диагностической работы, включая результаты исследований, доступна врачу с рабочего места, в реальном времени;

5. Обеспечения врача необходимыми информационными ресурсами: непосредственно в процессе оказания медицинской помощи врач имеет доступ к актуальным данным.

При создании программного приложения были проанализированы следующие средства реализации [2]:

1. Power Designer, которые поддерживает средства построения моделей и диаграмм, методологию UML, CDM, PDM и возможности хранилищ данных. Данное программное приложение поддерживает возможности командной разработки

2. Oracle – мощная и устойчивая СУБД, работающая под управлением различных операционных систем, включая Windows 98, Windows 2000/XP, несколько вариантов Unix. Она является одной из самых популярных СУБД в мире и имеет длительную историю разработки и использования. Значительная часть технологии Oracle открыта для разработчика, что обеспечивает большую гибкость при ее конфигурировании и настройке.

Однако все это означает, что Oracle может быть не простой в установке, и для работы с ней необходимо многому научиться. Более того, методики, которые работают в версии Oracle, предназначенные для одной операционной системы, могут потребовать модификации в версии для другой операционной системы.

Существует много конфигураций программного пакета Oracle. Во-первых, существует две различные версии ядра СУБД Oracle: для индивидуального пользования и для организаций. Кроме того, имеется программа для разработки форм и отчетов, программа Oracle Designer и множество средств для публикации баз данных Oracle в WEB. [1]

3. SQL Navigator – самая популярная среда разработки под Oracle , предоставляющая широкие возможности по написанию, настройке и отладке библиотек PL/SQL, включающая встроенную экспертную систему и систему подсказок.

4. Delphi – является средой визуального проектирования, что позволяет быстро и качественно создавать программы в коллективе на производстве, значительно снизить затраты времени на подготовку приложений, а также согласовать деятельность группы поставщиков, кодировщиков, тестеров и технических писателей. Ещё одним достоинством Delphi является её межплатформенность, т.е. возможность компиляции Windows-приложений в формат Kylix для Linux.

Анализ технического задания. В общем случае средства программной поддержки врача терапевта можно представить совокупностью трех автоматизированных рабочих мест (АРМов):

- АРМ «Регистратура»

- АРМ «Врач-терапевт»

- АРМ «Администратор»

АРМ «Врача-терапевта»

Рассматривая работу врача – терапевта в общем случае, можно отметить, что к нему поступает пациент с карточкой и, возможно, результатами дополнительного диагностического обследования, а основной его задачей является выработка схемы лечения пациента, в которую могут войти различные процедуры, медикаментозная терапия, посещение узких специалистов и т.д. Врач терапевт должен разобраться в проблемах пациента, определить в какой стадии находится то или иное заболевание и решить, что делать пациенту для улучшения своего самочувствия. Всю работу по подготовке принятия решения можно разбить на несколько этапов: описание состояния пациента, клиническое обследование, постановка диагнозов, определение целей терапии, постановка критериев достижения целей терапии, анализ состояния пациента и синтез схемы лечения на основе полученной информации. Интерфейс врача терапевта должен быть построен в соответствии с приведенной схемой. Основной формой АРМа должна быть форма отображения пациентов, которые проходят лечение у данного врача и их посещений к врачу. Посещения могут быть нескольких типов: первичный прием, повторный прием, профилактическая консультация. Для каждого типа посещения в АРМе врача — терапевта должен выбираться свой инструментарий для работы с пациентом. У формы отображения пациентов должны быть те же возможности по поиску и фильтрации соответствующих записей, что и у формы отображения АРМа регистратора. Для боле тонкой классификации типов посещения пациентов должно быть введено понятие — цель посещения. Так, например, Кроме того, в идентификаторах списка должно быть поле даты следующего прихода пациента. Форма приема пациента должна быть организована в виде соответствующего мастера, который представляет работу в логической последовательности. На первом этапе мастера регистрируются жалобы пациента, анамнез заболевания пациента, анамнез жизни пациента, аллергологический анамнез, проводится опрос по органам и системам. Если до приема врачом пациент прошел диагностирующую процедуру, которая каким — либо образом исключает заболевания некоторых органов и систем, то опрос стоит сократить, для экономии времени врача. Кроме того, на первом этапе работы мастера имеется возможность провести диагностическую процедуру в рамках АРМ «Дополнительная диагностика». При приеме пациента, с целью узнать его состояние опрос следует начинать с регистрации жалоб пациента. Необходимо узнать:

1. На что жалуется больной.

2. Точная локализация болезненных явлений.

3. Иррадиация боли.

4. Время появления (днем/ночью)

5. Факторы, вызывающие болезненные ощущения (физическое или психическое напряжение, прием пищи и т.р.).

6. Характер болезненного ощущения, например характер боли: сжимающий, колющий, жгучий, постоянный, приступообразный и т.д. , а также его интенсивность, продолжительность

7. Чем купируется болезненное явление

8. Поведение больного, вынужденное положение больного, облегчающие болезненные ощущения.

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

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

1. В течение, какого времени считает себя больным?

2. Где и при каких обстоятельствах заболел впервые?

3. Факторы, способствующие началу заболевания

4. С каких признаков началось заболевание?

5. Первое обращение к врачу, результаты проводившихся исследований, диагноз заболевания, лечение в тот период, его эффективность.

6. Последующее течение заболевания

Вторым этапом работы мастера проведения приема пациента, является клинический осмотр, проводящийся врачом – терапевтом. В рамках клинического осмотра врач проводит внешний осмотр пациента, пальпацию, перкуссию, аускультацию, с целью определения состояния различных органов и систем, съем ЧП, съем АД, замер роста, определение массы тела. Информация о результатах каждого вида осмотра регистрируется врачом в соответствующих полях мастера проведения осмотра.

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

АРМ «Администратор»

На уровне АРМа «Администратор» осуществляются следующие виды работ:

- конфигурирование клиники;

- настройка АРМов;

- настройка справочников.

Анализ аналогичных программных систем. «АИС «Поликлиника» [1-4]. Компания КРОК разработала и внедрила автоматизированную информационную систему для центральной поликлиники ФСБ России (АИС «Поликлиника»). Система охватывает 340 автоматизированных рабочих мест, ее пользователями являются более 700 медицинских работников, обслуживающих свыше 5 тысяч человек в сутки. Система предназначена для комплексного информационно-аналитического обеспечения работы поликлиники. Система, центральным программным компонентом которой является медицинская информационная система «МедАналитика», также включает в себя серверное, компьютерное, сетевое и периферийное оборудование, подключенную к городской телефонной сети учрежденческую АТС, структурированную кабельную систему, высокоскоростную локальную вычислительную сеть, а также системы электропитания и охранной сигнализации.

Медицинская автоматизированная система “МедИС-Т”. Система предназначена для автоматизации производственной медицины, поликлиник, стационаров, здравпунктов, санаториев. Имеет возможность удаленного администрирования рабочих мест системы (через Internet).

Реализация программного приложения. С помощью программной системы Power Designer 15 была реализована концептуальная модель данных. Так как для регистрации жалоб пациента необходимо заполнять практически одни и те же поля для каждой жалобы, было принято решение разработать абстрактную таблицу регистрации жалоб.

Были разработаны следующие таблицы:

- Tusers – содержит данные о пользователях системы.

- Tpacient – карточка пациента.

- Tzalob – содержит жалобы пациента.

- T_boby_system – системы организма человека.

- T_ boby_pod_system – вид жалобы на конкретную систему организма.

- Tonsp_obch – таблица для определения настоящего состояния пациента.

- Tanamnez – анамнез заболевания.

- Tanamnez_next- последующее течение заболевания

- Tdiaznoz – содержит диагноз пациента.

- T_pod_diaznoz- содержит сопутствующие главному диагнозы.

С помощью программной системы Power Designer 15 на основе концептуальной модели данных была получена физическая модель данных, ориентированная на Oracle (см. рис. 1).

Создание представлений (views) [5, 6]. Представление – это результат SQL выражения, состоящего из операторов выборки, проектирования и соединения. Представления позволяют обеспечить более гибкую защиту таблиц, с их помощью можно ограничить доступ к определенным столбцам или строкам, а также они могут быть использованы для соединения таблиц.

Рис. 1 – Модель данных

Структура представления:

Create or replace view «v_имя таблицы» («имя_поля 1»,« имя_поля 2»…« имя_поля n» ) as select «имя_поля 1»,« имя_поля 2»…..« имя_поля n» FROM «имя таблицы» WHERE DEL=0

Где DEL – поле пометки на удаление

Для каждой таблицы были созданы представления вышеописанной структуры.

Создание последовательностей(sequences). Последовательность – это объект, который генерирует серию последовательных уникальных чисел. Последовательности чаще всего используются для генерации значений суррогатных ключей.

Создание триггеров (triggers). Триггеры в Oracle – это процедуры на языке Java или SQL, которые вызываются при выполнении определенных действий с базой данных. Oracle поддерживает несколько типов триггеров: одни запускаются командами SQL, создающие в базе данных новые структуры, например таблицы, другие запускаются единожды а уровне таблицы, когда происходит изменение строк таблицы, третьи запускаются по одному разу для каждой измененной строки.

Структура созданных триггеров:

BEGIN SELECT SEC_«имя_таблицы».NEXTVAL INTO :NEW. «Идентификатор_таблицы» FROM DUAL; END;

Реализация клиентской части программного приложения. Программа состоит из следующих модулей:

- login_Unit – модуль, предназначенный для входа в систему.

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

- Admin_Unit – модуль, предназначенный для отображения списка зарегистрированных пользователей системы.

- Main_Unit – Главная форма приложения.

- Find_User_Unit – модуль, предназначенный для ввода данных необходимых для поиска.

- New_User_Unit – модуль, предназначенный для добавления нового пользователя.

- Edit_User_Unit – модуль, предназначенный для редактирования данных пользователя.

- Reg_nit – модуль, предназначенный для отображения карточек пациентов.

- New_Pacient_Unit – модуль, предназначенный для внесения в базу данных нового пациента.

- Edit_pacient_Unit – модуль, предназначенный для редактирования данных пациента.

- Pacient_Unit – модуль, предназначенный для отображения пациентов в АРМ «Врач-терапевт».

- Choose_Date_Unit– модуль, предназначенный для выбора даты.

- Reg_Zalob_Unit – модуль, предназначенный для регистрации жалоб пациента.

- Detail_zalob_Unit– модуль, предназначенный для детализации зарегистрированных жалоб.

- Edit_Unit – модуль, предназначенный для ввода большого объема данных.

- Anamnez_Unit – модуль, предназначенный для описания анамнеза заболевания.

- new_zalob_Unit – модуль, предназначенный для внесения новой жалобы в базу данных.

- Edit_Zalob_Unit – модуль, предназначенный для редактирования я жалоб.

- Opred_Sost_Unit – модуль, предназначенный для определения настоящего состояния пациента.

- Diagnoz_Unit – модуль, предназначенный для вынесения главного диагноза и сопутствующих ему диагнозов.

- Sost_Unit_– модуль, предназначенный для просмотра состояний пациента на разные даты. Служит для определения динамики развития пациента.

- Edit_Sost_Unit – модуль, предназначенный для редактирования данных о состоянии пациента .

- Restore_Users_Unit – модуль, предназначенный для восстановления ошибочно удаленных пользователей системы.

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

- Restore_Pacient_Unit – модуль, предназначенный для восстановления ошибочно удаленных пациентов.

- Restore_diagnoz_Unit – модуль, предназначенный для восстановления ошибочно удаленных диагнозов пациентов.

Структура программного приложения приведена на рисунке 2.

После запуска программного приложения на экране монитора отобразится форма, которая предложит пройти процедуру аутентификации (см. рис 3). Для входа в систему необходимо будет ввести «логин» и «пароль» в соответствующие поля формы.

После входа в систему отобразится главная форма программного приложения (см. рис 4). Данная форма не является информативной и предоставляет только выбор режима работы с приложением:

- АРМ «Администратор»;

- АРМ «Регистратура»;

- АРМ «Врач-терапевт».

Рис. 2 – Структура программного приложения

В случае если у пользователя не назначены права на какой-либо режим работы с системой, то для данного пользователя этот режим будет недоступен. 

Рис. 3 – Форма входа в систему

Рис. 4 – Главная форма программного приложения

АРМ «Администратор». После входа в систему в режиме администратора на экране отобразится форма АРМ «Администратор» (см. рис. 5).

На форме отображены пользователи системы, а также права этих пользователей. С этими данными можно производить следующие действия:

- Добавить – отображение формы добавления нового пользователя (см. рис. 6).

Для корректного добавления пользователя необходимо заполнить все поля, а также распределить права для пользователя, после чего необходимо нажать на кнопку «Добавить».

Рис. 5 – Форма АРМ «Администратор»

Рис.6 – Форма добавления нового пользователя

- Изменить – отображение формы редактирования данных пользователя. Данная форма аналогична форме добавления нового пользователя.

- Удалить – данная функция предназначена для удаления пользователя. Физически данные из базы не удаляются. В любой момент возможно восстановление удаленных данных.

- Поиск – активация формы ввода строки поиска (см. рис. 7).

Рис.7 – Форма ввода строки поиска

После ввода строки поиска необходимо нажать на кнопку «Найти».

- Отмена – функция предназначена для отмены результатов поиска.

Также администратор имеет возможность восстановления удаленных данных. Для восстановления пользователей системы существует специализированная форма (см. рис. 8)

Рис.8 – Восстановление пользователей системы

Чтобы восстановить пользователя необходимо указать его в списке удаленных пользователей, а затем нажать кнопку «Восстановить».

Для восстановления удаленных пациентов существует специализированная форма восстановления пациентов (см. рис. 9)

Рис. 9 – Восстановление пациентов

Чтобы восстановить пациента необходимо указать его в списке удаленных пациентов, а затем нажать кнопку «Восстановить».

Для восстановления удаленных диагнозов существует специализированная форма восстановления диагнозов (см. рис. 10.)

Рис. 10 – Восстановление диагнозов

Чтобы восстановить диагноз необходимо указать его в списке удаленных диагнозов, а затем нажать кнопку «Восстановить». Чтобы восстановить сопутствующий диагноз необходимо указать его в списке удаленных сопутствующих диагнозов, а затем нажать кнопку «Восстановить». Диагноз будет восстановлен у того пациента, у которого он был удален.

АРМ «Врач-терапевт». После активации режима врача терапевта, на экране отобразится форма отображения пациентов (см. рис. 11).

На форме отображены пациенты, закрепленные за конкретным врачом.

С этими данными можно производить следующие действия:

- Выбор пациентов, записанных на конкретное число. Для активации данной функции необходимо нажать на кнопку «Пациенты».

Рис. 11 – Форма АРМ «Врач-терапевт»

На экране отобразиться форма выбора даты (см. рис. 12)

Рис. 12 – Форма выбора даты

По окончании выбора даты необходимо нажать на кнопку «Просмотр».

- Поиск – активация формы ввода строки поиска(см. рис. 7).

- Отмена – функция предназначена для отмены результатов поиска.

- Начать прием – активация мастера приема пациента.

Первым этапом приема пациента является регистрация жалоб пациента (см. рис. 13).

Рис. 13 – Форма регистрации жалоб пациента

На данной форме отображены жалобы пациента. С этими данными можно производить следующие действия:

- Добавить – активация формы добавления жалобы пациента (см. рис. 14).

Рис. 14 – Форма добавления жалобы пациента

- Детализировать – активация формы детализации жалобы пациента (см. рис. 15).

- Редактировать – данная форма аналогична форме детализации жалобы пациента.

- Удалить – данная функция предназначена для удаления карточки пациента. Физически данные из базы не удаляются.

Рис. 15 – Форма детализации жалобы пациента

После регистрации жалоб пациента, и их детализации необходимо перейти к описанию анамнеза заболевания. Для этого необходимо заполнить поля на двух вкладках:

- Анамнез заболевания (см. рис. 16).

- Последующее течение заболевания (см. рис. 17).

После описания анамнеза заболевания необходимо приступить к определению состояния пациента. В случае если пациент посещал врача неоднократно, благодаря данной форме, возможно отследить динамику развития заболевания (см. рис. 18).

Рис. 16 – Вкладка описания анамнеза заболевания

Рис. 17 – Вкладка описания последующего течения заболевания

С данными формы можно проводить следующие действия:

- Добавить – активация формы определения состояния пациента (см. рис. 19).

- Редактировать – активация формы редактирования состояния пациента. Данная форма аналогична форме определения состояния.

После описания анамнеза заболевания необходимо приступить к вынесению диагноза (см. рис.20).

Рис. 18 – Форма отображения состояния пациента

Рис.19 – Форма определения состояния пациента

После вынесения диагноза можно завершить мастер приема пациента.

 Рис. 20 – Форма вынесения диагнозов

Разработанное программное приложение можно использовать для автоматизации рабочего места врача санатория.

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

Причин много. Это и несовершенство организационных основ процесса разработки [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].