Автоматизация ключевых бизнес-процессов санатория на основе итерационной модели внедрения информационных систем

Подробности

Опубликовано: 10.07.2018 11:29

Автор: Симанков Артем Владимирович

Просмотров: 4507

Аннотация: в работе реализуется автоматизация ключевых бизнес-процессов санатория на основе итерационной модели внедрения информационных систем и создание таких механизмов, которые позволят упростить трудоемкость работы, ускорить время ее выполнения и сделать процесс работы врача более комфортным, благодаря внедрению автоматизированной системы.
Скачать: PDF, PPT, MP4.
Ключевые слова: жизненный цикл информационной системы, life cycle, инкрементный подход, Kano model, управляющие процессы, преобразование данных, анализ временных промежутков, декомпозиция процесса, нотация ARIS, неключевые атрибуты, user interface, пользовательский интерфейс, VBA код.

Введение

Здоровье граждан является одним из основных приоритетов  общественного, экономического и культурного развития любой страны. В крепком здоровье граждан страны – залог роста трудовых резервов, повышения культурного уровня,  общенационального и  международного ее престижа. В качестве приоритетного направления повышения уровня здоровья граждан в РФ избраны – профилактика и предупреждение заболеваний, качественное медицинское обслуживание граждан и их реабилитация. Трудно переоценить положительный эффект от профилактических мероприятий, лечебных и восстановительных процедур, осуществляемых в заведениях санаторно-курортного типа. Данная практика дает возможность значительно снизить количество возникновения и обострения хронических и иных заболеваний. В связи с чем,  все большее количество граждан предпочитают проводить время отдыха в санаторных учреждениях. Помимо применения восстановительных и лечебных свойств и условий природного характера в учреждениях санаторно-курортного типа начали значительное время отводить под процедуры, являющиеся действенными способами системной терапии многих заболеваний, которые оказывают также  неоценимый и профилактический эффект. На данный момент большая часть  санаторно-курортных учреждений осуществляет  хранение медицинской документации (карт) по пациентам   в бумажном виде (картотека). Ведение картотеки  пациентов на бумажных носителях затрудняет работу персонала по  поиску и обработке необходимых данных. Требует значительных затрат по хранению, созданию условий  и  обеспечению  их сохранности. Ведение  базы  по пациентам учреждения требует ее систематического обновления. Внесение изменений, дополнений и обновлений  в бумажные носители  в ручном режиме – трудоемкая процедура, требующая нерационального отвлечения труда сотрудников санаторно-курортного учреждения от  непосредственного обслуживания пациентов/клиентов учреждения. Для структуризации всех сведений о клиентах санатория, их диагнозе и процедурах необходимо внедрить специализированные автоматизированные системы. Такой подход даст возможность ощутимо повысить скорость обработки и обмена данными, увеличить качество предоставляемых услуг и сократить количество ошибок, Целью данного проекта является автоматизация ключевых бизнес-процессов санатория на основе итерационной модели внедрения информационных систем и создание таких механизмов, которые позволят упростить трудоемкость работы, ускорить время ее выполнения и сделать  процесс работы врача более комфортным, благодаря внедрению автоматизированной системы. Это позволит врачу-курортологу выбрать тот перечень процедур, который необходим пациенту для оздоровления и профилактики. Таким образом, чтобы реализовать вышеупомянутую цель нужно реализовать следующие задачи:

• детальный анализ итерационной методологии внедрения систем;
• идентификация требований и формирование бэклога;
• проектирование процессов и оргструктуры в моделях AS-IS и TO-BE  нотации IDEF0 и DFD до 3-4 уровней детализации.

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

• моделирование разрабатываемых пользовательских интерфейсов; 
• проектирование структуры данных и нормализация таблиц данных;
• реализация операции ключевого процесса в среде MS Access;
• тестирование и количественная оценка результатов тестирования;
• подготовка блок-схемы алгоритма работы программы.

Раздел 1. Методология внедрения итерационной модели программных продуктов

1.1. Формулировка жизненного цикла и его модели

Понятие жизненного цикла (Life Cycle) информационной системы (ИС) подразумевает основополагающую базу методологии проектирования информационных систем. Жизненный цикл можно представить, как последовательность решений и операций, которые устанавливают путь развития любой системы, программы или иного проекта, начиная с принятия решения о создании ИС, этапов работы над ее созданием, тестированием, внедрением в эксплуатацию и заканчивая окончательным завершением ее применения и отказом от ее использования.  А также показывающие происходящие с системой в процессе создания и использования изменения. 

Модель жизненного цикла информационной системы – это определенная упорядоченная структура, означающая не только последовательность выполнения процессов, целей и действий, происходящих в процессе эксплуатации, но и определяющая взаимосвязанность между процессами, целями и действиями. Модель жизненного цикла – структура, состоящая из процессов, работ и задач,  включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [1].

1.2. Понятие итерационная модель, ее основные черты и качества специфика

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

Рис. 1.1. Итерационная схема внедрения информационных систем

Жизненный цикл проекта при итерационной разработке разделен на поочередные итерации, при этом каждая из них включает в себя все про-цессы разработки  ПО:

• определение и спецификация требований;
• проектирование;
• непосредственную реализацию; 
• тестирование; 
• введение в эксплуатацию. 

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

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

Если инкрементная модель применяется для разработки проекта, но при этом не является подходящей для него в полной мере, она может проявить ряд отрицательных качеств:

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

Целесообразность использования в разработке итерационной модели можно проследить по таким условиям:

• если большая часть требований может быть выражена на первых этапах разработки, но при этом их возникновение предполагается через какое-то время;
• есть необходимость в быстрые сроки создать продукт с основными базовыми качествами, для его выставления для продажи;
• для долговременных проектов, для реализации которых необходим большой период (год и более);
• когда при анализе рисков, финансирования, графика реализации проекта, масштабов программы, уровня ее сложности или возникновения потребности в ее осуществления на ранних этапах выясняется, что наиболее эффективным способом будет использование принципа поэтапного создания;
• при реализации проекта с использованием новых методик, что дает возможность пользователю приспосабливаться к программному продукту посредством осуществления менее крупных инкрементных операций, не приступая сразу к использованию основного функционала [3].

За последовательность итераций должны быть реализованы такие действия, как:

• анализ требований;
• моделирование ключевого бизнес-процесса с помощью нотаций IDEF0 и DFD (разработка структуры, декомпозиция компонентов);
• реализация требований (разработка программы в среде MS Access): моделирование пользовательского интерфейса, проектирование структуры данных и нормализация таблиц данных, реализация ключевого бизнес-процесса;
• тестирование программы (анализ программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта);
• исправление ошибок;
• демонстрация прототипа программы заказчику.

Раздел 2. Идентификация требований, формирование списка требований 

2.1. Идентификация требований

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

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

• полноту и законченность описания продукта;
• адекватность процесса идентификации требований к продукту;
• адекватность результата, то есть то, что продукт соответствует поставленной цели [4]. 

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

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

Анализ требований может представлять из себя долгий и трудоемкий процесс. Новые системы преобразовывают окружающую действительность и взаимоотношения между людьми, следовательно необходимо установить всех заинтересованных субъектов, учесть все их запросы и обеспечить  осознание ими важности новых систем [6]. 

2.2. Пользовательские требования

Пользовательские требования – это требования, которые формулируются пользователями к конечному продукту. Эти требования  представляют собой  задачи и  идеи, которые пользователям дадут возможность для комфортного пользования разработанным программным средством. Ниже определены требования, предъявляемые пользователями к проектируемой системе:

• База данных должна хранить:
  • личные данные о пациенте; 
  • данные о диагнозе;
  • данные о проводимых процедурах;
  • данные о врачах.
• Установка процедуры по диагнозу. Автоматический выбор процедуры по определенному диагнозу.
• Возможность осуществлять действия с электронной медицинской картой:
  • добавление (создание новой записи о пациенте);
  • редактирование (изменение некорректной информации);
  • удаление (удаление неактуальных данных или полное удаление информации о пациенте);
• Печатать и выводить эпикриз с назначенными процедурами.
• Осуществлять поиск пациента.
• Программа должна иметь возможность составлять отчеты по необходимым категориям и за определенное время.
• Легкость в освоении медицинским персоналом (простота и легкость в пользовании  интерфейса).
• Вся информация хранится на персональных компьютерах санатория.

2.3. Функциональные требования

Функциональные требования – это требования, объясняющие, что должно быть в разрабатываемом ПО, а также, какие действия должны выполняться системой:

• База данных должна включать в себя таблицы:
  • «Пациенты». Содержится информация о ФИО пациента, дате рождения, пол и др.;
  • «Диагноз». Содержится информация о диагнозе;
  • «Процедуры». Содержится информация о процедуре, количестве, кратности, дате начала и окончания процедуры, а также комментарий для работника процедурного кабинета;
  • «Врачи». Содержится информация о враче (ФИО и др.).
• Автоматизировать выбор процедуры по поставленному диагнозу.
• Создать возможность вывода на экран электронной карточки пациента, в которой можно внести или изменить данные о пациенте.
• Обеспечивать:
  • создание новых данных в таблицах «Пациенты», «Диагноз», «Процедуры», «Врачи»;
  • изменение данных в таблицах «Пациенты», «Диагноз», «Процедуры», «Врачи»;
  • удаление данных в таблицах «Пациенты», «Диагноз», «Процедуры», «Врачи».
• Выводить данные на экран монитора:
  • полная личная информация о пациенте;
  • информация о диагнозе;
  • информация о процедурах;
  • информация о процедурах для диагноза.
• Пользовательский интерфейс программы должен обеспечивать наглядное, интуитивно понятное представление структуры размещенной на нем информации, быстрый и логичный переход к разделам и страницам.
• Печать отчета, содержащего личные данные пациента и список проведенных процедур.

2.4. Приоритизация требований

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

Установить определенную очередность выполнения целей можно, основываясь на разных параметрах и отталкиваясь от разных соображений. С этой целью было выработано большое количество методик приоритизации, каждая из которых основывается на разных параметрах важности цели. Применим модель Кано (Kanо model). Главная задача данной модели состоит в гарантировании удовлетворенности требований заказчика и конечного пользователя, иными словами это одно из средств регулирования уровня качества. Цель данной модели состоит в установке всех существующих требований и расстановке их в порядке убывающего приоритета. Его природа состоит в дифференциации требований на четыре группы, отображающие степень значимости каждой возможности программы для пользователя:

• необходимые (must-be) – при их отсутствии пользователь не рассматривает данный продукт. Однако их наличие не приводит к высокой удовлетворенности пользователя, поскольку воспринимается им как нечто само собой разумеющееся; 
• одномерные (one-dimensional) – чем в большей степени такие характеристики присутствуют или лучше их качество, тем выше удовлетворенность ими пользователя;
• привлекательные (attractive) – отсутствие данного атрибута воспринимается пользователям нейтрально и не препятствует выбору, тем не менее его присутствие резко увеличивает удовлетворенность потребителя;
• безразличные (indifferent) – эти характеристики не имеют значения для пользователя и не влияют на его выбор [7]. 

2.5. Список требований

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

Таблица 2.1. Список требований

При создании программного продукта по итерационной модели рекомендуется производить разработку по следующим шагам.

Таблица 2.2. Циклы разработки итерационной модели

 Раздел 3. Проектирование ключевых бизнес-процессов в моделях  «AS-IS» и «TO-BE»

Моделирование – это замена реального объекта, процесса, явления его определенным аналогом, который конструктивно проще своего оригинала, но при этом в нем отображаются все специфические черты с позиции задачи моделирования, что может содействовать в исследовании «исходника». Моделирование используется в различных областях жизнедеятельности, в частности в экономике.

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

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

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

Модель «AS-IS» нередко подразумевается в качестве функциональной и реализуется с применением разного рода графических нотаций. На стадии проектирования AS-IS необходимо создавать наиболее близкую к реальности модель, которая базируется на фактических процессах, а не на их идеальных копиях. Проектирование информационных систем и управление процессами подразумевает построение модели AS-IS и дальнейший переход к модели TO-BE, что является залогом автоматизации "правильных", усовершенствованных процессов.

Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. Сюда нужно отнести установку субъекта, осуществляющего моделирование, целей и позиции относительно проекта. Под субъектом предполагается сама система. При этом нужно четко определить, что в нее входит, а что находится вне ее границ. Иными словами  необходимо установить элементы системы и внешние связи. На установление субъекта системы значимым образом оказывает воздействие точка зрения, с которой рассматривается система и цели моделирования – вопросы, на которые сформированный проект должен ответить. То есть, на первом этапе нужно выяснить сферу проектирования. Характеристика сферы как  системы, а также ее элементов служит фундаментом для формирования проекта.

Обычно сначала строится модель существующей организации работы – AS-IS (как есть). На основе модели AS-IS можно прийти к определенному балансу между разными структурными подразделениями организации относительно их вклада в общее дело организации и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перейти на то, "что мы будем делать завтра".

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

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

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) – модели, которая отображает новое построение бизнес-процессов. Модель ТО-ВЕ необходима для нахождения иных, более оптимальных методов организации и отображения в документации проектов будущей деятельности фирмы [8]. 

3.1. Способы проектирования

IDEF0 – методология функционального моделирования, снабженная наглядным графическим языком и позволяющая представить моделируемый процесс в виде набора взаимосвязанных функций. Моделирование средствами IDEF0 является первым этапом изучения бизнес-процесса.  

Функциональные модели выделяют действия посредством представления в виде специального элемента – функционального блока. Блок, изображающий некоторую бизнес-функцию, является центральным элементом нотации IDEF0. Элементы, используемые в нотации IDEF0 представлены в таблице 3.1.

Таблица 3.1. Условные обозначения нотации IDEF0 

Графический элемент	Описание
	Функциональный блок. Представляет собой некоторый конкретный процесс в рамках рассматриваемой системы
	Вход,  входящие  в  левую  грань  стрелки  изображают данные или объекты, изменяемые  в ходе  выполнения бизнес-процесса
	Выход, выходящие из правой грани стрелки изображают данные или объекты, появляющиеся в результате выполнения бизнес-процесса
	Управление, входящие в верхнюю грань стрелки изображают правила и ограничения, согласно которым выполняется бизнес-процесс
	Механизм, входящие в нижнюю грань стрелки изображают ресурсы, необходимые для выполнения бизнес-процесса, но не изменяемые им

Основным преимуществом данной методологии является возможность описания бизнес-процессов верхнего уровня и возможности отображения регулирования процессов, обратных связей и потоков данных. Среди слабых сторон следует отметить трудность для понимания диаграмм, множество уровней декомпозиции, которое необходимо для полной характеристики процесса, сложность связывания нескольких процессов. Для этих целей используют нотацию DFD (Data Flow Diagram – диаграмма потока  данных) [9]. 

Цель  представления DFD нотации — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. Может отражать не только информационные, но и материальные потоки. Также как и в других моделях, поддерживается декомпозиция. Диаграмма потока данных является основным средством моделирования функциональных требований к системе – проектируемой или реально существующей. Главной сильной стороной этой нотации являются: возможность описания процессов нижнего уровня, требуемой для разрешения проблемы логической недоработанности модели и формирования полной функциональной спецификации для разрабатываемой системы, возможность моделирования сверху вниз, возможность нотации в точности установить внешние структуры, применяя анализ потоков данных в пределах и снаружи системы [10]. Элементы, используемые в процессе моделирования с помощью нотации DFD, приведены в таблице 3.2 [1]. 

Таблица 3.2. Условные обозначения нотации DFD

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

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

3.2. Проектирование процессов в AS-IS с помощью IDEF0 и DFD

Первый уровень описания процесса врача-курортолога в модели AS-IS с помощью нотации IDEF0 заключается в выполнении трех процессов: А1 – «Принять пациента», А2 – «Провести лечение», А3 – «Выписать пациента». Эти процессы показаны на рисунке 3.1.

Рис. 3.1. Первый уровень описания ключевых бизнес-процессов в AS-IS нотации IDEF0

Выполним декомпозицию процессов А1 и А3. Таким образом, получим второй уровень описания процессов IDEF0 (рис. 3.2-3.3).

Рис. 3.2. Бизнес-процесс А1 «Принять пациента» на втором уровне описания в AS-IS нотации IDEF0

Рис. 3.3. Бизнес-процесс А3 «Выписать пациента» на втором уровне описания в AS-IS нотации IDEF0

Проведем декомпозицию процесса А2 «Провести лечение», получив второй уровень описания процессов нотации IDEF0 (рис. 3.4).

Рис. 3.4. Бизнес-процесс А2 «Провести лечение» на втором уровне описания в AS-IS нотации IDEF0

Второй уровень описания не несет в себе информации, поэтому следует рассмотреть  подпроцесс А2-2 «Определить процедуру» более подробно. Выполнение декомпозиции второго уровня описания с помощью IDEF0 невозможно, так как в дальнейшем вовлекаются хранилища данных. Поэтому целесообразно использовать нотацию DFD. Результат декомпозиции показан на рисунке 3.5.

Рис. 3.5. Бизнес-процесс А2-2 «Определить процедуру» на третьем уровне описания в AS-IS нотации DFD

3.3. Проектирование процессов в TO-BE с помощью IDEF0 и DFD

После рассмотрения структуры процессов в нотации AS-IS, необходимо рассмотреть структуры процессов в модели TO-BE. На рисунке 3.6 изображены процессы в модели «Как будет» нотации IDEF0.

Рис. 3.6. Первый уровень описания ключевых бизнес-процессов в TO-BE нотации IDEF0

Подобным образом произведем декомпозицию процессов А1 и А3 (рис. 3.7-3.8).

Рис. 3.7. Бизнес-процесс А1 «Принять пациента» на втором уровне описания в TO-BE нотации IDEF0

Рис. 3.8. Бизнес-процесс А3 «Выписать пациента» на втором уровне описания в TO-BE нотации IDEF0

Аналогично, для более подробного рассмотрения подвергнем процесс А2 «Выдать оптимальную процедуру» декомпозиции (рис. 3.9).

Рис. 3.9. Бизнес-процесс А2 «Выдать оптимальную процедуру» на втором уровне описания в TO-BE нотации IDEF0

Выполнение декомпозиции второго уровня не представляется возможным из-за фигурирования хранилища данных. Поэтому применим нотацию DFD. Графическое представление декомпозиции второго уровня представлено на рисунке 3.10.

Рис. 3.10. Бизнес-процесс А2-2 «Идентифицировать процедуру» на третьем уровне описания в TO-BE нотации DFD

Используя описанные ранее бизнес-процесс на 1-3 уровнях, построим карту процессов в нотации ARIS и модели «Как будет» (рис. 3.11).

Рис. 3.11. Карта процессов в нотации ARIS модели «Как будет» 

Раздел 4. Разработка приложения

4.1. Моделирование данных разрабатываемой системы

Процесс моделирования основывается на методике нормализации, иными словами декомпозиции связей, которые находятся в предыдущей нормальной форме, в две либо больше связи, которые соответствуют следующей нормальной форме. Данные могут группироваться в таблицы (классы данных) разными способами. При проектировании приложения может использоваться одна универсальная связь, в которую включаются все необходимые атрибуты [11]. Она может содержать все данные, которые предполагается размещать в БД (табл. 4.1).

Таблица 4.1. Классы данных 

Используем нормализацию данных, чтобы исключить избыточное дублирование данных в базе. Оптимально производить нормализацию до третьей нормальной формы. Согласно первой нормальной форме (1НФ) необходимо:

• определить ключевые поля;
• обеспечить содержание только одного значения на пересечении каждого столбца строки.

Таким образом, зададим ключевые поля для класса «Пациенты», «Диагноз», «Процедуры». Обеспечим содержание только одного значения для каждого атрибута. Для этого в классе «Пациент» разделим поле «ФИО» на три строки: «Фамилия», «Имя», «Отчество»; «Пол», «Место проживания» на строки: «Республика/край/область», «Город», «Район», «Тип местности»; поле «Время пребывания» на строки: «Дата поступления», «Дата выписки», «Проведено дней» (табл. 4.2).

Таблица 4.2. Нормализация данных первой нормальной формой 

Произведем нормализацию до второй нормальной формы (2НФ). Для этого необходимо: декомпозировать отношения, в которых неключевые атрибуты будут зависеть от ключа. Следовательно, не ключевые атрибуты ключа «Код пациента» добавляются в промежуточные таблицы: «Пациенты_Диагнозы» (Код_Записи, Код_Пациента, Код_диагноза, Дата), «Пациенты_Процедуры» (Код_Записи, Код_Пациента, Код_Диагноза, Код_Процедуры, Количество,  Дата_Начала, Дата_Окончания, Комментарий). Не ключевые атрибуты ключей «Код_Диагноза», «Код_Процедуры» добавляются в промежуточную таблицу: «Диагнозы_Процедуры» (Код_Записи, Код_Диагноза, Код_Процедуры). Данные о врачах вынесем в отдельную таблицу «Врачи» (табл. 4.3).

Таблица 4.3. Нормализация данных второй нормальной формой 

Для приведения к третьей нормальной форме (3НФ) данные должны соответствовать условиям 2НФ и необходимо, чтобы ни один из его не ключевых атрибутов не связан функциональной зависимостью с любым другим не ключевым атрибутом. Атрибуты, зависящие от других не ключевых атрибутов, нормализуются посредством перемещения зависимого свойства и того, от которого он зависит, в новое отношение. Проведя нормализацию данных, получим архитектуру данных, приведенную к третьей нормальной форме (рис.4.1).

Рис. 4.1. Архитектура данных разрабатываемой системы 

4.2. Описание интерфейса разрабатываемого приложения

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

Интерфейс двунаправленный. устройство, получив команды от пользователя и исполнив их, выдаёт информацию обратно, наличествующими у неё средствами (визуальными, звуковыми и т. п.), приняв которую, пользователь выдаёт устройству последующие команды предоставленными в его распоряжение средствами (кнопки, переключатели, регуляторы, сенсоры, голосом, и т. д.) [4]. Интерфейс должен создаваться принимая во внимание параметры качества любого интерфейса: скорость осуществления операций, удобство, уровень производительности, быстрота адаптации и личная удовлетворенность пользователя. Для этого необходимо создать макет главного экрана приложения, который содержит следующие кнопки: «Справочная информация», «Личные данные пациента», «Поиск по пациентам», «Карточка пациента»,  «Установить диагноз», «Карта выбывшего из санатория», «Отчёты» (рис.  4.2).

Рис. 4.2. Главный интерфейс приложения

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

Рис. 4.3. Интерфейс «Справочная информация»

Если необходимо произвести поиск пациента, достаточно перейти по кнопке «Поиск по пациентам» (рис. 4.4).

Рис. 4.4. Интерфейс «Поиск по пациентам»

Чтобы добавить нового пациента, пользователю  достаточно выбрать «Карточка пациента» и перейти в таблицу добавления записи о новом пациенте (рис.4.5).

Рис. 4.5. Интерфейс «Карточка пациента»

Если пользователю необходимо выбрать процедуру для пациента, то требуется выбрать кнопку «Установить диагноз», выбрать диагноз из выпадающего списка, а подходящие процедуры появятся ниже (рис. 4.6).

Рис. 4.6. Интерфейс «Установить диагноз»

После выписки пациенту выдается «Карта выбывшего из санатория» (рис. 4.7-4.8).

Рис. 4.7. Интерфейс «Установить диагноз»

Рис. 4.8. Интерфейс «Карта выбывшего из санатория», информация о пациенте

Если пользователю необходимо составить отчет, то нажав на кнопку «Отчеты», можно выбрать одну из представленных форм отчетов (рис. 4.9).

Рис. 4.9. Интерфейс «Отчеты»

Исходя из спроектированных выше интерфейсов, составим схему работы приложения (рис. 4.10 – 4.11).

Рис. 4.10. Схема работы приложения (часть 1)

Рис. 4.11. Схема работы приложения (часть 2) 

4.3. Первый образец программы (Итерация 1)

Реализация первых двух пользовательских требований «Хранение личных данных пациента, диагноз, процедуры, врачи» и «Автоматический выбор процедуры»  подразумевает собой создание таблиц в среде разработки MS Access. В базу данных включены таблицы: «Пациенты», «Диагноз», «Процедуры», «Врачи», в которых хранятся соответствующие данные (рис. 4.12).

Рис. 4.12. Фрагмент БД таблицы «Пациенты»

Рис. 4.13. Схема данных приложения

Далее, необходимо создать «промежуточные» таблицы «Пациенты_Диагнозы», «Пациенты_Процедуры», «Диагнозы_Процедуры», которые потребуются для реализации основного бизнес-процесса «Автоматический выбор процедуры» (рис. 4.13). 

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

Рис. 4.14. Интерфейс «Установить диагноз» с возможностью выбора диагноза и постановки процедуры 

4.4. Второй образец программы (Итерация 2)

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

Рис. 4.15. Главный интерфейс приложения для работы с таблицами

Реализуем электронную медицинскую карту с целью упрощения работы врача и уменьшения времени работы с документацией (рис. 4.16).

Рис. 4.16. Интерфейс «Карточка пациента» для работы с таблицей «Пациенты» 

4.5. Третий образец программы (Итерация 3)

Третья итерация направлена на реализацию требования № 5 «Просмотр записей диагнозы пациентов, процедуры пациентов, врачи» основная цель которой – формирование отчетов. В среде MS Access они необходимы для вывода на экран определенной информации из базы данных. Разработаем интерфейс для удобной навигации между кнопками отчета (рис.4.17-рис.4.18).

Рис. 4.17. Интерфейс «Отчеты» для работы с отчетами

Рис. 4.18. Отчет «Процедуры, назначенные пациентам»

Создание «Карта выбывшего из санатория» подразумевает реализацию требования № 6 «Вывод эпикриза с назначенными процедурами». Это необходимо для взаимного обмена информацией между медицинскими учреждениями (рис.4.19).

Рис. 4.19. Интерфейс «Карта выбывшего из санатория» 

4.6. Четвертый образец программы (Итерация 4)

Разработка  требования № 7 «Осуществление поиска пациента» включает в себя создание запросов для поиска нужной информации среди всей базы данных. Запрос с названием «Поиск» позволяет по любой части фамилии найти конкретного пациента (рис. 4.20).

 Рис. 4.20. Окно поиска процедур и диагноза пациента

Отобразим реализацию данного требования программно путем представления VBA кода на рисунке 4.21 [12].

Рис. 4.21. Листинг программы по поиску пациента

Составим блок-схему алгоритма работы программы. Это позволит наглядным способом представить работу ключевого бизнес-процесса (рис. 4.22) [13]. Подобный запрос помогает пользователю отследить процедуру, дату ее начала и окончания (рис. 4.23).

Рис. 4.22. Блок-схема работы «Поиска пациента»

Рис. 4.23. Таблица с выданным запросом по поиску процедур и диагнозу на пациента Васечкина

Исходя из требования № 8 «Легкость в освоении медицинским персоналом» для удобства работы с программой необходимо сформировать интуитивно понятный интерфейс, который обладает такими функциями доступности: общепонятность, простота, легкость (рис. 4.24)

Рис. 4.24. Главное меню приложения

Реализация требования № 9 «Печать эпикриза» предоставляет возможность вывода на печать необходимой информации. Таким образом   отобразить «Карта выбывшего из санатория» на бумажный носитель предоставляется возможным (рис.4.25).

Рис. 4.25. Окно с возможностью печати «Карта выбывшего из санатория»

Раздел 5. Тестирование разработанного приложения

5.1. Функциональное тестирование

Функциональное тестирование – вид тестирования, целью которого является проверка правильности работы функционала разрабатываемого приложения (корректность реализации функциональных требований). Его задача состоит в определении того, какие возможности продукта были разработаны и в проверке того, что они функционируют должным образом  [14]. Для проверки реализации функциональных требований проведем их анализ.

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

Рис. 5.1. Таблицы «Пациенты»,  «Процедуры», «Диагноз» в MS Access

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

Рис. 5.2. Таблица «Диагноз_Процедуры» в MS Access

Третье функциональное требование обязует возможность исправления удаления и внесения новой информации  о пациенте в таблицу данных «Пациенты»,  «Процедуры», «Диагноз». Ниже, в графическом представлении продемонстрируем возможность работать с данными в выше упомянутых таблицах (рис. 5.3, рис. 5.4, рис. 5.5).

Рис. 5.3. Таблица «Пациенты» с возможностью работы с данными

Рис. 5.4. Таблица «Процедуры» с возможностью работы с данными

Рис. 5.5. Таблица «Диагноз» с возможностью работы с данными

Функция просмотра данных из БД «Пациенты», «Процедуры», «Диагноз» позволяет вывести на экран запрашиваемые данные благодаря созданным отчетам. Представим программную реализацию данного требования и корректность ее работы на рисунке 5.6.

Рис. 5.6. Отчет «Процедуры, назначенные пациентам»

Возможность поиска записей по пациентам предоставляет найти записи в таблице по фамилии, дате рождения, полу. Изучим правильность работы программы на примере поиска пациента по фамилии Алешин (рис. 5.7). Результат поиска показан на рисунке 5.8.

Рис. 5.7. Окно поиска процедур и диагноза пациента Васечкина

Рис. 5.8. Таблица с выданным запросом по поиску процедур и диагнозу на пациента Васечкина

Рис. 5.9. Главное меню приложения

Функция доступности предполагает возможность любому пользователю легко взаимодействовать с системой (интерфейсом приложения). Если пользователю будет непонятно или трудно разбираться с приложением, он, скорее всего, просто откажется от этого. Следовательно, любо приложение должны быть понятными для пользователя на уровне интуиции (рис. 5.9).

Место хранения в различных условиях должно соответствовать требованиям, предъявляемым к носителям информации на которых будет содержаться данное программное изделие. Программа может храниться на жестком диске персонального компьютера, на Flash-носителе, на компакт-дисках. Из вышесказанного можно сделать вывод, что функциональное тестирование показало отсутствие ошибок и полную работоспособность ПО. Результаты тестирования свидетельствуют о том, что все функциональные требования успешно реализованы.

5.2. Интеграционное тестирование

Интеграционное тестирование – тестирование, которое проводится с целью проверки правильного взаимодействия между несколькими элементами приложения. Данный вид тестирования производит глубокую проверку взаимодействия компонентов в ситуации, когда пользователю почти нечего наблюдать, т. к. все представляющие интерес и подвергаемые тестированию процессы проходят на уровнях более глубоких, чем пользовательский интерфейс. Главные цели интеграционного тестирования состоят в тестировании составляющих модулей программы на неконфликтность и соответствие требованиям. Следующая цель заключается в тестировании корректности взаимодействия нескольких модулей, объединенных в единое целое [14]. Достаточно проверить корректность поиска введенной ранее информации. Вызовем запрос на поиск пациента (рис.5.10).

Рис. 5.10. Запрос на поиск пациента

Рисунок 5.11 содержит таблицу, демонстрирующую правильность запрашиваемой ранее информации.

Рис. 5.11. Таблица с выданным запросом по поиску процедур и диагнозу на пациента Васечкина

5.3. Нагрузочное тестирование

Нагрузочное тестирование заключается в проверке возможности приложения сохранять требуемые параметры при воздействии предельных нагрузок и определенном превышении пределов [10]. Для данного тестирования взято следующее количество записей пациентов: 10, 50, 100. Определим время отклика при работе с разным количеством записей и занесем значения в табл. 5.2 в столбцы 3-5.

Далее, определим среднее арифметическое всех значений времени отклика для определенного количества записей и занесем в столбец 6. Среднее арифметическое значение рассчитывается по формуле:

                                                                               (5.1)

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

                                                                                        (5.2)

где N– число значений. Погрешность измерений рассчитывается по формуле:

                                            (5.3)

где   – доверительный коэффициент Стьюдента, равный 0.95;   – абсолютная погрешность электронного секундомера равная 0,005, которым производилось измерение [15]. Время отклика определяется:

                                                               (5.4)

Данные по нагрузочному тестированию приведены в таблице 5.2.

Таблица 5.2. Результаты нагрузочного тестирования 

Раздел 6. Расчет затрат на разработку и внедрение программного продукта 

6.1. Расчет заработной платы исполнителей проекта

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

Таблица 6.1. Стадии и этапы разработки и внедрения программного продукта 

Произведем расчет затрат на оплату труда. Затраты на оплату труда состоят из основной заработной платы и дополнительной заработной платы. Основная зарплата начисляется исходя из отработанного времени и оклада. Расчет основной заработной платы производится по формуле (6.1). 

                                                                                   (6.1)

Расчет заработной платы руководителя (ЗП_рук.) и разработчика (ЗП_раз.) производится делением месячного оклада на количество рабочих дней в месяц (22 дня) с последующие умножением на продолжительность работ [16]. Представим данные в таблице 6.2. 

Таблица 6.2. Основная заработная плата исполнителей проекта

Подставив в формулу (6.1) числовые значения, вычислим основную заработную плату исполнителей проекта:  .

Расчет дополнительной заработной платы осуществляется на основании 15 % от основной заработной платы по формуле (6.2).

                                                                                (6.2)

Подставим в формулу (6.2) числовые значения:   . Таким образом, рассчитаем фонд оплаты труда по формуле (6.3). 

                                                                                       (6.3)

т.е.  

6.2. Расчет затрат на электроэнергию, амортизацию оборудования и прочих затрат

Произведем расчет материальных затрат, исходя из того, что при разработке и внедрении программного продукта оборудование и специальное программное обеспечение не приобреталось. Таким образом, в расчет затрат включаем только расходы на электроэнергию. Тогда, расчет затрат на электроэнергию осуществляется по формуле (6.4).

                                                                                        (6.4)

где Р – потребляемая мощность оборудования, кВт/ч; Ц_эл – стоимость 1 кВт/ч, руб.; Т_и – время использования оборудования при проведении работ, ч. [16].

При разработке, тестировании, отладке программного продукта использовался один персональный компьютер с потребляемой мощностью 500 Вт/ч, который работал 57 рабочих дней по 8 часов. Стоимость 1кВт энергии составляет 4,37 руб./кВт (на 2019 год) [17]. Подставив в формулу (6.4) числовые значения вычислим материальные затраты:  

Далее произведем расчет затрат на амортизацию оборудования. Амортизационные отчисления учитываются в сметной стоимости научно-исследовательской и опытно-конструкторской работы и рассчитываются по формуле (6.5):

                                                                                      (6.5)

где Ф_перв – первоначальная стоимость оборудования, руб.; Т_и – время использования оборудования при проведении работ, дн.; Н_а – норма амортизации; Ф_эф – годовой эффективный фонд времени работы оборудования, для односменной работы он составляет 256 дн. [16].

Норма амортизации На является величиной, обратной сроку службы оборудования, и считается по формуле (6.6):

                                                                                                            (6.6)

где Т_пи – срок службы оборудования, лет [16].

Срок службы компьютера – 2-3 года (на 2019 г.) [18]. Тогда норма амортизации рассчитывается следующим образом:  . Затраты на амортизацию оборудования за 57 дней использования для компьютера стоимостью в 55000 руб. составят:  

Общие прямые затраты рассчитываются по формуле (6.7), как сумма затрат на заработную плату, затрат на электроэнергию и затрат на амортизацию оборудования:

                                                                     (6.7)

Подставив в формулу (6.7) числовые значения и рассчитаем сумму прямых затрат:    Расчет прочих расходов подразумевает расчет страховых взносов и дополнительных прочих расходов по формуле (6.8):

      (6.8)

Ставка страховых взносов в 2019 г. составляет 30%  от величины фонда оплаты труда [19]. Таким образом, страховые взносы составят: 968613,7*0,3 =290584,1 руб.

Величина дополнительных прочих расходов рассчитывается как 10% от суммы прямых затрат. Дополнительные прочие затраты: 973651,3*0,1 = 97365,1 руб. В итоге, прочие затраты составят: З_пр = 290584,1+97365,1 =387949,2 руб.

6.3. Расчет сметы затрат

Общие затраты на разработку и внедрение программного продукта – это сумма прямых затрат и прочих затрат. Расчет производится по формуле (6.9):

                                                                                       (6.9)

Подставив в формулу (6.9) числовые значения, вычислим значение общих затрат на разработку и внедрение программного продукта: З = 973651,3 + 387949,2 = 1361601,0 руб.

В таблице 6.3 представлена смета затрат на разработку и внедрение программного продукта.

Таблица 6.3. Смета затрат

Таким образом, можно сделать следующий вывод. Основная часть затрат – 71,7%, необходимых на реализацию проекта, составляют затраты на заработную плату. Прочие затраты составляют 28,5% от общей суммы затрат по проекту. Затраты на электроэнергию и амортизацию оборудования составляют 0,1% и 0,3% от общей суммы затрат соответственно.

Заключение

Целью данной работы являлось создание приложения для автоматизации работы врача-курортолога в санатории. Стояла необходимость в создании механизмов, которые дадут возможность снизить трудозатраты, сократить временные расходы и повысить комфорт условий  труда медицинского персонала учреждений. Для выполнения данной задачи требовалось исследовать и определить все пользовательские требования. Отталкиваясь от них, формировались функциональные требования, на основе которых проходила разработка программного продукта. После этого был составлен план разработки приложения согласно итерационной модели. В результате были получены четыре итерации, в ходе которых реализовывались новые функции, а также те, которые были разработаны в процессе прошлых итераций.

После окончания анализа требований мы приступили к проектированию и моделированию основных бизнес-процессов учреждения, AS-IS и TO-BE в нотации IDEF0 и DFD для того, чтобы представить разницу «до» и «после» внедрения разрабатываемой системы на каждом уровне организации. Поскольку создание приложения происходило в среде MS Access, требовалась классификация и нормализация данных и моделирование их архитектуры. Создание пользовательских интерфейсов позволило представить, как будет выглядеть приложение в конце. Целью создания интерфейса являлось обеспечение возможности обновления представленных данных по деятельности санатория без использования программирования и специального кодирования. Создание блок-схемы действия алгоритма программы оказалось удобным средством описания, демонстрирующее наглядный принцип работы ключевого бизнес-процесса с помощью геометрических фигур с линиями-связями.

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

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

Список литературы

1. Федорова Г.Н. Информационные системы: учебник для студ. учреждений сред. проф. образования // Издательский центр «Академия», 2013 – 208 с.
2. Барышникова М.Ю.Инженерный менеджмент и информационные технологии. Конспект лекций. М.: МГТУ им. Н. Э. Баумана, 2009. - 252 с.
3. Карпенко С.Н., Вершинина Е.В., Гонченко М.С. Обзор моделей жизненного цикла разработки программного обеспечения// Математические и программные технологии для современных компьютерных систем (Информационные технологии), 2017 – 69с.
4. Идентификация требований и определения спецификаций. Конспект лекций. М.: Томский Политехнический Университет. URL: https://studfiles.net/preview/4241597/page:8/ (дата обращения: 01.11.2018)
5. Свободная энциклопедия Википедия, статья «Анализ требований».URL:https://ru.wikipedia.org/wiki/Анализ_требований (дата обращения: 02.11.2018)
6. Лешек А. Мацяшек Анализ требований и проектирование систем. // Издательский дом «Вильямс», 2005 – 432 с.
7. Fieldboom, статья «The Kano Model Explained: Analysis and Examples». URL: https://www.fieldboom.com/kano-model (дата обращения: 02.11.2018)
8. Клебанов Б.И. Проектирование автоматизированных систем обработки информации и управления. Методические указания к выполнению курсового проекта М.: Уральский государственный технический университет, 2004. – 66 с.
9. Самуйлов К.Е., Серебренникова Н.В., Чукарин А.В., Яркина Н.В. Основы формальных методов описания бизнес-процессов: Учебное пособие. – М.: РУДН, 2008 – 130 с.
10. Морозов Д.А. Применение нотации DFD в моделировании внешних схем // Портал научно-практических публикаций [Электронный ресурс]. URL: http://portalnp.ru/2014/06/2015 (дата обращения: 05.11.2018)
11. Дейт К. Дж. Введение в системы баз данных, 8-е издание. // Издательский дом «Вильямс», 2010 – 1328 с
12. Культин Н. Б. Цой Л. Б. Visual Basic для студентов и школьников // Издательство «БХВ – Петербург», 2010 – 401 с.
13. Идентификация требований и определения спецификаций. Конспект лекций. М.: Томский Политехнический Университет. URL: https://studfiles.net/preview/4241597/page:8/ (дата обращения: 01.11.2018)
14. Афанасьева Т.В. Основы визуальной алгоритмизации: Учебное пособие для студентов. – М.: Ульяновский государственный технический университет, 2012 – 64 с.
15. Куликов С.С. Тестирование программного обеспечения. Базовый курс. – Минск: Четыре четверти, 2017. – 312 с.
16. Рабинович С.Г. Погрешности измерений. // Издательство «Энергия», 2008 – 262 с.
17. Методические указания по выполнению экономического (организационно-экономического) раздела выпускной квалификационной работы бакалавра (для студентов технических направлений подготовки)): учеб. пособие; Российский технологический университет (МИРЭА), 2019. - 45 с.
18. Энергосбытовая компания «Мосэнергосбыт», Тарифы на электрическую энергию для населения и приравненных к нему категорий потребителей на территории г. Москвы. URL: https://www.mosenergosbyt.ru/website/faces/individuals/tariffs-n-payments/tariffs-msk/polnaya-versiya-tarifov/
19. Постановление Правительства РФ от 01.01.2002 N 1 (ред. от 28.04.2018) "О Классификации основных средств, включаемых в амортизационные группы". – [Электронный ресурс]. – Режим доступа: http://www.consultant.ru/document/cons_doc_LAW_34710/ (дата обращения 07.05.2019)
20. Постановление Правительства РФ от 28.11.2018 N 1426 «О предельной величине базы для исчисления страховых взносов на обязательное социальное страхование на случай временной нетрудоспособности и в связи с материнством и на обязательное пенсионное страхование с 1 января 2019 г». – [Электронный ресурс]. – Режим доступа: https://normativ.kontur.ru/document?moduleId=1&documentId=325340/ (дата обращения 07.05.2019)

Выходные данные

Симанков А.В. Автоматизация ключевых бизнес-процессов санатория на основе итерационной модели внедрения информационных систем: диплом бакалавра / МИРЭА. – М., 2019. – 69 с. – URL: https://stepanovd.com/training/20-vkr/100-vkrb-2019-5-simankov.