ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ
ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ»
(НИУ «БелГУ»)
ПЕДАГОГИЧЕСКИЙ ИНСТИТУТ
ИСТОРИКО-ФИЛОЛОГИЧЕСКИЙ ФАКУЛЬТЕТ
КАФЕДРА РОССИЙСКОЙ ИСТОРИИ И ДОКУМЕНТОВЕДЕНИЯ
ДОКУМЕНТИРОВАНИЕ РАЗРАБОТКИ И ВНЕДРЕНИЯ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ
В ОРГАНИЗАЦИИ
(НА ПРИМЕРЕ ПРОГРАММНОГО ПРОДУКТА JUICE-CRM)
Выпускная квалификационная работа
обучающегося по направлению подготовки
46.04.02 Документоведение и архивоведение
очной формы обучения, 02031609 группы
Нефёдова Сергея Николаевича
Научный руководитель
кандидат исторических наук,
доцент Папков А.И.
Рецензент
Коннов Ю.В.
БЕЛГОРОД 2018
СОДЕРЖАНИЕ
ВВЕДЕНИЕ.............................................................................................................3
ГЛАВА
1.
ПРОБЛЕМА
ДОКУМЕНТАЦИОННОГО
ОБЕСПЕЧЕНИЯ
ПРОЦЕССА РАЗРАБОТКИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ.............7
§1. Потребность документирования процесса автоматизации управления.......7
§2.
Нормативная
база
документирования
разработки
и
внедрения
автоматизированных систем................................................................................22
ГЛАВА
2.
ДОКУМЕНТАЦИОННОЕ
ДЕЙСТВУЮЩИХ
ОБЕСПЕЧЕНИЕ
АВТОМАТИЗИРОВАННЫХ
ВНЕДРЕНИЯ
СИСТЕМ
«ДЖУС
ДЕВЕЛОПМЕНТ» ................................................................................................32
§1.
ООО
«Джус
Девелопмент»
как
разработчик
программного
обеспечения...........................................................................................................32
§2. Характеристика JUICE-CRM..........................................................................36
§3. Анализ оформления документов, связанных с обеспечением деятельности
программного продукта........................................................................................44
ГЛАВА 3. РАЗРАБОТКА СИСТЕМЫ ДОКУМЕНТИРОВАНИЯ РАЗРАБОТКИ И
ВНЕДРЕНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ.................................................48
§ 1. Проектирование унифицированной формы технического задания на
разработку автоматизированной системы..........................................................48
§
2.
Проектирование
унифицированной
формы
паспорта
на
автоматизированную систему..............................................................................53
ЗАКЛЮЧЕНИЕ.....................................................................................................57
БИБЛИОГРАФИЧЕСКИЙ СПИСОК..................................................................59
ПРИЛОЖЕНИЯ.....................................................................................................64
3
ВВЕДЕНИЕ
Актуальность.
совокупность
Автоматизированная
программно-аппаратных
информационная
средств,
система
предназначенных
—
для
автоматизации деятельности, связанной с хранением, передачей и обработкой
информации.
Основная
трудность
создания,
внедрения
и
эксплуатации
автоматизированной системы порождается противоречивостью требований к
информационному
обеспечению
со
стороны
пользователей,
имеющих
отношение к управлению. К пользователям имеют отношение любые субъекты,
обращающиеся к средствам информационного обеспечения за необходимой им
фактографической, документальной, аналитической и другой информацией и
использующие ее при выработке управленческих решений. Потребность в
использовании
автоматизации
различных
аспектов
управленческой
деятельности, имеющаяся в настоящее время с одной стороны, и отсутствие
единых, однозначно определённых требований к документации, которая сдаётся
при решении данной задачи, с другой стороны, определяют актуальность темы
настоящего исследования.
Степень изученности темы. При написании работы использовались
различные публикации, так
в работе
Н.А. Гайдамакина1
в которой
рассматриваются автоматизированные информационные системы и лежащие в
основе их создания и функционирования системы управления базами данных,
содержится информация о структуре и классификации автоматизированных
информационных
систем
и
СУБД,
модели
организации
данных
в
фактографических СУБД. Определённая информация была взята из интернетресурсов2.
Гайдамакин, Н.А. Автоматизированные информационные системы, базы и банки
данных. – М., 2002 – 312 с.
2
Внедрение
АИБС
«МАРК-SQL»
в
школьные
библиотеки.
–
URL:
http://www.gpntb.ru/win/inter-events/crimea2008/disk/107.pdf (дата обращения 26.05.2018).
1
4
В
работе
Л.Г.
Гагариной3
освещаются
вопросы
проектирования
автоматизированных информационных систем на основе анализа предметной
области, рассмотрены системы автоматизированного проектирования АИС,
средства автоматизированного проектирования структур баз данных. Изложены
также особенности эксплуатации АИС, методы и средства сбора и передачи
данных; обеспечение достоверности информации в процессе ее хранения и
обработки; экспортирование структур баз данных; восстановление информации в
базах данных.
В книге В.А. Гвоздевой4 рассматриваются классификация и структура
автоматизированных информационных систем (АИС), а также информационных
ресурсов и технологий, связанные с ними понятия и определения, роль
предметной
области.
Значительное
внимание
уделяется
стратегиям
проектирования АИС.
Существенное значение имеет работы В.В. Липаева5 и С.В. Назарова6, в
которых рассматриваются проблемы документирования автоматизированных
систем.
В работе были использованы статьи из периодических изданий
«Делопроизводство»7, «Новые системы финансового учета»8 и «Кадровик»9.
Документация
разработки
автоматизированной
систем.
–
URL:
http://www.philosoft.ru/systems.zhtml#dev/ (дата обращения 26.05.2018).
3
Гагарина Л.Г. Разработка и эксплуатация автоматизированных информационных систем.
- М., 2009. – 256 с.
4
Гвоздева В.А. Основы построения автоматизированных информационных систем. – М.,
2007. – 115 с.
5
Липаев В.В. Документирование сложных программных средств. – М., 2005. – 124 с.
6
Назаров С.В. Архитектуры и проектирование программных систем . — М., 2013. — 413
с.
7
Баласанян
В.Э. Применение автоматизированных систем документационного
обеспечения управления для повышения эффективного управления // Делопроизводство. –
2002.- № 2. – С. 27-30; Белая Т.Р. Автоматизированные системы документационного
обеспечения управления: организация создания АС ДОУ// Делопроизводство. – 2007. №3. – С. 40-44; Вовкотруб О.В. Создание автоматизированной системы для внутренних
описей // Делопроизводство. – 2003. - № 3. – С. 54-58; Кузнецов С.Л. Международные
требования к системам автоматизации делопроизводства // Делопроизводство. – 2006. - №
3. – С. 63-65.; Кузнецов С.Л. Примерное техническое задание на систему автоматизации
делопроизводства //Делопроизводство. – 2006. - № 1. – С. 45-48.
5
Анализ опубликованных научных работ позволяет говорить о наличии
серьёзной теоретической основы для решения вопроса документирования
разработки и внедрения автоматизированных систем в конкретной организации.
Объектом исследования является программный продукт, внедряемый в
различные организации компанией-разработчиком ООО «Джус Девелопмент».
Предметом
исследования
в
данной
работе
является
процесс
документирования разработки и внедрения программного продукта.
Цель исследования - разработать систему документирования процесса
внедрения программного продукта для компании «Джус Девелопмент».
Для достижения поставленной цели необходимо решить следующие
задачи:
- определить потребность документирования процесса автоматизации
управления;
- проанализировать нормативную базу документирования разработки и
внедрения автоматизированных систем в России;
- дать характеристику компании ООО «Джус Девелопмент» и продукта
JUICE-CRM;
- провести анализ оформления документов, связанных с обеспечением
деятельности программных продуктов ООО «Джус Девелопмент»;
- разработать систему документирования внедрения программного
продукта JUICE-CRM.
Анализ источников. При написании работы были использованы
государственные стандарты10, а так же локальные нормативные акты11
Козлов И. Программа не заменит человека. Проблема внедрения автоматизированных
систем // Новые системы финансового учета. – 2007. - № 4. С. 57-60.
9
Кучик Е. Любая автоматизированная система создается человеком // Кадровик. – 2008-№
11(15). – С. 57.
10
ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Термины и определения. –
М., 2002. – 20 с.; ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание автоматизированной
системы. – М., 2002. – 15 с.;ГОСТ 34.2001-89. Информационная технология. Комплекс
стандартов на автоматизированные системы. Виды, комплектность и обозначение
8
6
Методами исследования явились, прежде всего, изучение документов,
которое
позволило
определить
текущее
состояние
дел
в
области
документирования процесса разработки и внедрения автоматизированных
систем, как на уровне конкретной организации, так и на уровне общего
состояния нормативного регулирования данного вопроса. Метод личных
наблюдений позволил понять каким образом реализуются нормативные
требования и установить сложившуюся практику. Опрос и интервьюирование
дали возможность получить дополнительные сведения, необходимые для
анализа и разработки комплекса мер по совершенствованию процесса
документирования в изучаемой сфере.
Практическая значимость работы заключается в том, что результаты
исследования будут использованы организацией для разработки и внедрения
собственных программных продуктов, а после апробации и соответствующей
корректировки – могут быть предложены в качестве основы для решения
аналогичных задач другими организациями.
Структура работы в соответствии с поставленными задачами состоит из
введения, трех глав, заключения, библиографического списка и приложений. Во
введении обосновывается актуальность темы исследования, определяются его
цели и задачи. В первой определяется потребность в документировании
автоматизированных
систем,
а
также
определяется
нормативная
база
документации программных продуктов. Во второй главе даётся характеристика
организации и программного продукта, анализируется оформление документов,
связанных с обеспечением деятельности этой автоматизированной системы. В
документов при создании автоматизированных систем. – М., 2008. – 11 с.; ГОСТ 34.60190. Информационная технология. Комплекс стандартов на автоматизированные системы.
Автоматизированные системы стадии создания. - М., 1990. – 24 с.; ГОСТ Р 6.30-2003.
Унифицированные системы документации. Унифицированная система организационнораспорядительной документации. Требования к оформлению документов. – М., 2003. – 20
с.; ГОСТ 2.105.95 ЕСКД. Общие требования к текстовым документам. – М., – 30 с.; ГОСТ
2.301-68 ЕСКД Форматы. – М., 1990. – 4 с.
11
Устав Общества с ограниченной ответственностью «Джус Девелопмент» (утвержден
протоколом общего собрания участников Общества от 14.01.2017 № 01-01). – Белгород,
2017. – С. 3-4.
7
третьей
главе описан процесс проектирования комплекса документов,
сопровождающих
разработку и внедрение программного обеспечения.
Заключение посвящено выводам по результатам выполненного исследования.
Библиографический список состоит из источников, литературы и электронных
ресурсов. Работа включает 3 таблицы, 4 рисунка, 4 приложения.
8
ГЛАВА 1. ПРОБЛЕМА ДОКУМЕНТАЦИОННОГО ОБЕСПЕЧЕНИЯ
ПРОЦЕССА РАЗРАБОТКИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
§ 1.
Потребность документирования процесса автоматизации
управления
Документация является важной частью автоматизированной системы
для ЭВМ и требует значительных ресурсов для ее составления и
использования. Ресурсы информационных систем для ЭВМ могут стать
программным продуктом только в сопровождении с комплексом документов,
которые позволят его осваивать, применять и изменять. Для достижения
этого документы, сопровождающие программное обеспечение, должны быть
корректны, развёрнуто и доступно изложены, для возможности их успешного
освоения и использования специалистами различного уровня и назначения.
Полнота и качество отображения процессов и продуктов разработки в
жизненном цикле программных средств
должны полностью определять
достоверность информации для взаимодействия заказчиков, пользователей и
разработчиков. Посредством как электронных, так и бумажных документов,
специалисты взаимодействуют с программными средствами и данными в
реализующих их электронных вычислительных машинах, а также между
собой.
Создание
организационных
документации,
автоматизированной
усилий,
в
том
системы
числе
требует
создание
значительных
соответствующей
ибо документация автоматизированной системы – это
сложный элемент разработки, который подвержен постоянным изменениям,
вносимыми различными специалистами компании. Реализация документов
автоматизированной системы в значительной мере определяет качество
программных продуктов и трудозатраты разработки. Для этого необходимо
сформировать и использовать стратегию документирования, включающую в
9
себя стандарты оформления, распределение ресурсов и планы создания,
изменения и применения документов на программы и процессы жизненного
цикла автоматизированных информационных систем.
Для налаживания процесса документации и внедрения разработки
необходимо выделить руководителей и специалистов, которые будут
выполнять следующие задачи в создании пакетов документов:
планирование;
описание;
утверждение
выпуск;
распространение;
сопровождение.
Данные сотрудники также должны стимулировать непосредственных
разработчиков программ осуществлять
подробное документирование
процессов и результатов своей деятельности в реальном времени, а также
осуществлять контроль полноты и качества документов жизненного цикла
автоматизированной системы. Стратегия документирования, разработанная в
организации, занимающейся созданием программного обеспечения, должна
быть предназначена для специалистов, работающих с документацией
процессов жизненного цикла программного обеспечения, она устанавливает
требования, регламентирующие создание необходимых документов на
продукты и процессы.
Методы и средства документирования каждой процедуры в стандартах
обычно не раскрываются и адресуются к специальным нормативным
документам
различного
уровня.
Быстро
оснащающиеся
различными
методами и инструментальными средствами этапы системного анализа,
моделирования и проектирования программных средств различных классов и
назначения затрудняют стандартизацию этих процессов, достаточную для
10
полной формализации структуры и содержания документов на программы и
данные на уровне международных стандартов12.
Жизненный цикл автоматизированных систем в стандартах отражается
набором документов в последовательности выполнения и взаимосвязи задач,
обеспечивающих ведение разработки на всех стадиях от анализа и
проектирования технического задания до окончания испытаний и завершения
эксплуатации программного продукта. При разработке и использовании
сложных автоматизированных систем и обеспечении их жизненного цикла
документами, целесообразно использовать совокупность всех доступных
стандартов, описывающих основные процессы, работы и документы проекта.
В результате на первых этапах проектирования системы документации
необходимо выделить и сформировать комплект шаблонов документов,
регламентирующие все этапы, процессы и документы при создании
проектов. Для разработки и реализации положений этих документов должны
быть выбраны инструментальные средства, которые в совокупности
образуют единый комплекс технологической поддержки и автоматизации
этапов жизненного
цикла, не противоречащие пакету нормативных
документов.
Процесс
документирования
предусматривает
формализованное
описание информации, созданной в течение жизненного цикла программного
средства. Данный процесс состоит из набора действий, с помощью которых
планируют,
проектируют,
разрабатывают,
выпускают,
редактируют,
распространяют и сопровождают документы, необходимые для всех
заинтересованных лиц, таких, как руководство, технические специалисты и
пользователи системы13.
Затраты на документирование крупных программных продуктов могут
достигать 20 – 30% от общей трудоемкости проекта и необходимого числа
12
13
Липаев В.В. Документирование сложных… С. 7.
Назаров С.В. Архитектуры и проектирование… С. 32.
11
(многие десятки) специалистов в жизненном цикле проекта программного
средства. В более простых случаях, организация работ может быть упрощена,
затраты на документирование снижаются приблизительно до 10%, однако
всегда
целесообразно
ответственных
за
выделять
создание,
специалистов,
адекватность
и
непосредственно
контроль
полноценного
комплекта документов на программный продукт14.
Разработка
и
эксплуатация
программных
средств
сложных
автоматизированных систем документируется для возможности освоения и
развития программ и баз данных на любом этапе жизненного цикла, а также
для
связи
между
разработчиками
с
конечными
пользователями
программного обеспечения. По назначению и ориентации на конкретные
задачи и группы пользователей, документацию автоматизированных систем
можно поделить на два типа:
технологическая
документация
процессов
разработки
и
обеспечения всего жизненного цикла, которая включает в себя подробные
технические описания процессов, и подготавливаемую для специалистов,
ведущих
проектирование,
разработку
и
сопровождение
комплексов
программ, обеспечивающую возможность отчуждения, детального освоения,
развития и корректировки ими программ и данных на всем жизненном цикле
системы;
эксплуатационная
документация
программного
продукта,
создаваемая для конечных пользователей автоматизированной системы и
позволяющую им осваивать и квалифицированно применять эти средства для
решения конкретных функциональных задач систем.
Технологическая документация отражает процессы жизненного цикла
комплексов программ и данных и требования к этим документам. Стандарты
и
нормативные
документы,
входящие
в
жизненный
цикл
проекта
регламентируют структуру, этапы работы и их состав, а так же документы
14
Липаев В.В. Программная инженерия. – М., 2006. – С. 122.
12
жизненных циклов автоматизированных систем. Они должны формализовать
выполнение и документирование конкретных работ при проектировании,
разработке и сопровождении программ, адаптировать документы к среде
разработки,
регламентировать
процессы
обеспечения
качества
информационной системы и её компонентов, методы и средства их
достижения целей работ и показателей качества. Для контроля возможных
изменений
разработки
необходимо
вести
документ,
который
будет
регламентировать правила применения и корректировки номенклатуры, а
также состав и содержание документации, описывающей жизненный цикл
программного продукта.
Эксплуатационная
документация
обеспечивает
независимость
автоматизированной системы от поставщиков (компании-разработчика) и
освоение и эффективного применения комплексов программ конечными
пользователями. Эксплуатационные документы исключают возможность
некорректного использования функций автоматизированной системы
за
пределами условий эксплуатации, при которых гарантируются показатели
качества функционирования системы. Основная задача документов состоит
в
фиксировании,
использовании
и
обобщении
результатов
функционировании объектов и процессов всего жизненного цикла.
Документы в жизненном цикле программных средств должны отражать
сущность процессов и продуктов, доступную для анализа, освоения и
изменения разработчиками и конечными пользователями проектов. Поэтому
организация,
планирование,
формирование
и
реализация
регламентированных требований к структуре и содержанию документов,
сопровождающих автоматизированные системы, определяют значительную
часть успеха при создании и применении программных продуктов для ЭВМ.
Наибольшее влияние на качество документирования комплексов
программ оказывают: класс программного средства, его масштаб, связь с
реальным
масштабом
времени
и
степень
использования
готовых
13
апробированных компонентов. Эти показатели являются основой для выбора
технологической среды разработки, а также номенклатуры, структуры и
содержания документов. При этом возникает ряд организационных,
методологических и технологических проблем и задач, которые должны
решаться
при
подготовке
процессов
документирования
проектов
программных средств15.
Следует выделить 8 основных типов проблем, с которыми можно
столкнуться при создании системы документирования разработки и
внедрения автоматизированных систем.
Первая проблема, которую необходимо рассмотреть, это определение
потребности документирования автоматизированных систем, для решения
которых необходимо выполнить следующие этапы:
определить
документации,
заинтересованные
лица
и
пользователей
кто определяет потребность в разработке и конечную
эффективность проекта;
согласовать с заказчиком проекта определение наличия и
содержания возможных проблем создания документов на всех этапах
жизненного цикла разработки;
найти основные факторы появления проблем документирования
проекта;
установить ограничения, которые помогут решить проблемы
документирования.
Без
человека,
регламентирующего
требования
к
программе
и
документации, а также осуществляющего информационную поддержку
заказчика и разработчиков нельзя быть уверенным в том, что разработка идёт
верным путём. Для решения данной проблемы назначается ответственное
лицо – менеджер, владеющий концепцией и содержащимися в ней
основными задачами разработки. Также необходимо создать совет по
15
Липаев В.В. Документирование сложных… С.8.
14
контролю за изменениями проекта и документов, состоящий из менеджера и
команды
разработчиков,
который
позволит
отслеживать
проблемы,
возникающие в процессе документирования процессов жизненного цикла.
Недостаточное понимание требований заказчика к системе усложняет
процесс
документирования
действительности
автоматизированной
организация,
заказавшая
системы.
разработку
В
программного
продукта, редко предоставляет точные требования как к автоматизированной
системе,
так
и
сопровождающей
документации,
определить
эти
спецификации становится задачей разработчика. Для получения конкретных
требований к проекту необходимо прибегнуть к следующим методам:
анкетирование потенциальных клиентов и проведение интервью
с заказчиком;
совещания
заказчика
с
проект-менеджером
для
анализа
требований к проекту и его документам;
проверка
функционирования
форм
технической
и
эксплуатационной документации до её использования.
Таким
образом,
нами
была
решена
проблема
потребности
документирования, заключающаяся в трудностях взаимодействия между
разработчиком и конечным пользователем. Для достижения этой цели
необходимо назначить проект-менеджера, который станет связующим звеном
между исполнителями и заказчиком программного продукта и будет решать
вопросы согласования проектных решений в разработке системы и её
документации.
Второй проблемой документирования для разработчика являются
трудности определения системы, функций и характеристик программного
продукта.
Существует
информационная
иерархия:
от
потребностей
пользователей, передаваемых при помощи функций, до конкретных
требований
к
программному
продукту,
выраженных
посредством
прецедентов или традиционных форм описания документов. Данная модель
15
отражает степень абстракции при рассмотрении областей проблемы и
решения.
В
требованиях
к
документации
необходимо
зафиксировать
потребности пользователей в доступном виде, чтобы разработчик мог
построить удовлетворяющее их программное средство. Данные требования
должны быть наиболее конкретными, для чёткого понимания и их
достижения. Требования должны описывать количество пользователей,
участвующих в выполнении задачи, длительность цикла её выполнения,
сколько времени отводится на выполнение каждого действия, наличие
уникальных ограничений внешней среды, а также системы, которые уже
используются в организации. Необходимо указать схожие программные
продукты, которые уже существуют или могут появиться на рынке с
аналогичными текущей разработке функциями.
Функции и характеристика автоматизированной системы должны
содержать общее описание возможностей программы, взаимодействия с
другими
программными
продуктами
и
конфигурациями
систем
и
компонентов, как продукт взаимодействует с пользователями. Функции
должны быть описаны так, чтобы они были понятны неопытному
пользователю. Требования к функциям должны отражать преимущества
автоматизации её конечным пользователям.
Следующим элементом характеристики проекта является базовая
версия,
призванная отражать в какой версии предполагается впервые
реализовать
некоторую
функцию.
Эта
информация
применятся
для
определения приоритетов разработки и выявления компонентов, требующих
дополнительного исследования.
Завершающий вопрос данной проблемы – определение концепции
автоматизированной системы, которая позволит выполнять требуемые
задачи, обеспечивает основу для принятия решений в течение жизненного
цикла. В этом документе следует отразить сбалансированный образ функций,
16
удовлетворяющих различных заинтересованных лиц. Он может быть
несколько идеалистичным, но должен быть основан на существующих или
предполагаемых
стратегическом
рыночных
направлении
факторах,
развития
архитектуре
корпорации
предприятия,
и
ограничениях
ресурсов16.
Таким образом, для решения трудностей с
определением системы,
функций и характеристик программного продукта, необходимо определить
требования
к
документации,
потребности
конечных
пользователей,
утвердить функции системы и разработать концепцию проекта.
Нередко во взаимоотношениях заказчика и разработчика проекта
возникает недопонимание в процессе обсуждения срока выполнения работ и
их бюджета. Это связано с проблемами оценки и управления масштабом
проекта. Они обусловлены тем, что компания-заказчик изначально желает
получить продукт, обладающий функционалом, который исполнитель не
способен реализовать в установленный срок, либо не может обеспечить
необходимое качество данных работ.
Оптимальным решением будет установление ограничений на объём
работ в определённый период времени, дабы исполнитель мог предоставить
качественную реализацию элементов автоматизированной системы в срок,
предоставив соответствующую документацию.
Определять содержание работ для каждого версии продукта должен
заказчик, основываясь на приоритетах функций, которые необходимо
автоматизировать посредствам разработанного программного продукта.
Привлечение компании, для которой разрабатывается система, к
управлению масштабом проекта улучшает взаимопонимание и повышает
доверие между заказчиком и командой разработчиков документации и
самого
продукта.
На
этапе
анализа
среды,
которая
нуждается
в
автоматизации, компания должна определить бюджет, который она готова
16
Липаев В.В. Документирование сложных… С.14.
17
потратить на разработку программного продукта. Ограничения призваны
исключить завышенные ожидания заказчика от проекта, которые не могут
быть реализованы при данном бюджете, предлагая ему отказаться от
реализации данных функций в информационной системе или увеличить
объём ресурсов, выделенных для данного проекта. Иногда клиенты
запрашивают функции, слишком дорогостоящие или выходящие за
предполагаемые границы масштаба продукта. Разработчику необходимо
документировать отклоненные требования и причины отказа от них в
конечном техническом задании.
Первоначальная версия объединяет основные функции, которые
необходимо разработать, включенные в базовую версию автоматизированной
системы. Для соблюдения графика необходимо отказаться от включения в
первую версию функций, которые потенциально могут понадобиться
заказчику, но не влияют на основной функционал. Результатом подобных
инициатив разработчика будет увеличение сроков и смещение графика. Для
решения проблемы исполнитель должен сконцентрироваться на наиболее
ценных функциях, выполняющих основной функционал конечного продукта,
которые позволят сдать приложение в короткие сроки.
Дополнительные работы допустимо выполнять на конечных этапах
разработки,
дорабатывая
систему
после
сдачи
основной
версии
программного обеспечения. В последующих версиях продукта можно
реализовать дополнительные функции, а также расширить возможности
первоначальных подсистем.
Для решения этого комплекса проблем необходимо документировать
объём работ, выполняемых разработчиком, согласовать сроки и бюджет
проекта с заказчиком, правильно расставлять приоритет в выполнении тех
или иных работ, своевременно сдавать отчётную документацию заказчику о
выполненных работах.
18
Проблема построения системы документов решается использованием
нормативной
базы
документирования
автоматизированных
систем,
используя её для построения архитектуры сопровождающих документов и их
использования.
Следить за расширением функций и требований к проекту, а также его
статус разработки поможет верификация. С помощью трассировки можно
удостовериться в том, что все компоненты проекта в документах учтены, и
все они служат основной цели, она является важным показателем качества
реализации
программы
на
стадиях
спецификации,
архитектуры,
проектирования, реализации и тестирования.
Способность отслеживать отношения и находить их связи при
возникновении изменений является основной нитью многих современных
высоконадежных программных процессов, особенно в медицине (устройства
жизнеобеспечения) и других критически важных областях17.
В процессе формирования стратегии, стандартов и руководства по
документированию программного средства необходимо определить модель
жизненного цикла разработки и состав документов в нём, составить формы
для каждого сопровождающего документа, определить формат и систему их
обозначения, а так же установить порядок реализации данной системы
документации.
Для обеспечения документирования комплексов программ необходимо
решить проблему организационной структуры коллектива. Компании
разработчика необходимо определить состав подразделений и должностных
лиц, которые будут обеспечивать документирование этапов жизненного
цикла проекта, и использовать документы сторонних организаций при
принятии решений, регламентировать их работу обозначив их обязанности.
Разработка и сопровождение документации на автоматизированную
систему должны обеспечивать длительный жизненный цикл, мобильность и
17
Липаев В.В. Экономика производства программных продуктов. – М., 2011. – С. 192.
19
повторное применение программных и информационных компонентов,
независимо от их первичных разработчиков.18
Задачами менеджеров проекта вместе с его заказчиками является
обеспечение разработчиков:
официальными отчетами и руководствами по принятой стратегии
документирования конкретной разработки;
нормативной базой документирования программ и данных;
инструментами
и
рекомендуемыми
процедурами
автоматизированного документирования разработки системы, её процессов и
документов;
ресурсами, необходимыми для реализации документирования
программ и данных;
планами документирования жизненного цикла проекта;
своевременными консультациями для обеспечения полноценного
и унифицированного документирования всех компонентов и процессов
жизненного цикла.
Проблема согласования и утверждения требований заказчика и
разработчиков на проект и документацию программного средства должны
осуществляться, используя при этом принятую в соответствующем бизнесе
терминологию. Выявляя требования заказчика, аналитики и менеджеры
разработчика могут лучше понять задачи и осознать, какое место уготовано
создаваемому программному средству у заказчика. Аналитики должны
отсортировать и выявить функциональные требования, цели и возможные
решения в области создания и применения автоматизированной системы.
Конечный итог этого анализа – спецификация требований к программному
средству
и
документам,
представляющая
собой
соглашение
между
разработчиками и заказчиком о функциях, качестве, документах и
ограничениях создаваемого продукта. Чтобы гарантировать, что новая
18
Липаев В.В. Документирование сложных… С. 17.
20
система не будет автоматизировать неэффективные или устаревшие процессы,
аналитики должны знать, почему существующие системы не годятся для
заказчика. Иногда пользователи просят, чтобы продукт был дружественным,
надежным или эффективным, однако эти термины слишком субъективны,
чтобы помочь разработчикам. Поэтому аналитики должны выяснять и
документировать конкретные характеристики, означающие эти пожелания.
Аналитику могут быть известны готовые программные компоненты и
документы,
которые
практически
полностью
удовлетворят
некоторые
потребности заказчика. В таком случае следует скорректировать отдельные
требования, чтобы разработчики могли использовать имеющиеся компоненты
конечного продукта. Если считается разумным включить в продукт готовые
коммерческие
компоненты,
следует
проявить
гибкость,
поскольку
характеристики таких компонентов вряд ли будут точно соответствовать
исходным потребностям. Для принятия правильных решений необходимы
данные об эффективности и стоимости предполагаемого изменения требований.
Следующая
проблема,
которую
необходимо
предусмотреть,
это
доступные ресурсы разработки. В них входят финансовые, кадровые и
аппаратурные ограничения, в условиях которых предстоит проектирование
сопровождающих документов. Некоторые ресурсы однозначно предопределяют
параметры средств автоматизации разработки, а другие более или менее
существенно влияют на выбор технологий и номенклатуры разрабатываемых
документов. Специалисты, разрабатывающие программное обеспечение, лучше
всего способны оценить необходимые затраты денежных средств и человекочасов на реализацию различных функций.
Может оказаться, что некоторые необходимые заказчику функции
технически невыполнимы или их реализация слишком дорога, и просто
недоступна. Изменения могут стоить дорого, и сроки будут нарушены, если
клиент пожелает реализовать в практически завершенном проекте новую
функциональность.
21
Для минимизации негативного влияния подобных изменений необходимо
выполнять процедуры регулярного контроля их разработки. Это обеспечит
возможность отслеживать каждое требование и согласованность коррективов
между собой, будут проанализированы изменения в работе системы от каждой
доработки.
Последняя
проблема,
которую
необходимо
рассмотреть
при
проектировании системы документации – прогнозирование физического
объема
комплекса
документов
для
конкретных
проектов
разработки
программного средства.
Добавление уникальных или специфических документов должно быть
оговорено в договоре на разработку программного обеспечения. Структура и
содержание форм сопроводительных документов на автоматизированную
систему не конкретизируется вследствие большого числа неопределенных
параметров. Эти вопросы решаются индивидуально с использованием
руководящих
документов
по
подготовке
и
оформлению
конкретных
эксплуатационных и технологических документов для пользователей и
разработчиков определенных проектов. Стороны ответственны за выбор и
применение методов и инструментальных средств автоматизации разработки и
оценки суммарных размеров совокупности документов, а также за выбор
процедур и документов, подходящих для оценки конкретного проекта ПС или
системы.
В данном параграфе была дана характеристика документирования
программных средств, выделены виды сопроводительной документации,
определены основные проблемы, с которыми разработчик может столкнуться
при создании программных средств, а также определены методы их решения –
разработка соответствующих документов, которые в комплексе будут
представлять собой систему документирования разработки и внедрения
автоматизированных систем.
22
§ 2. Нормативная база документирования разработки и внедрения
автоматизированных систем
С каждым годом масштаб применения автоматизированных систем в
различных компаниях и их сложность их разработки за счёт нового
функционала растёт, что вызывает потребность наличия полной, точной и
понятной эксплуатационной документации на эти программные средства,
доступной
конечным
пользователям.
Стандарты
определяют
способ
достижения данной цели, устанавливая состав работы и исполнителя,
обеспечивающие качество и унификацию документации пользователя
программных средств. Для достижения высокого качества сопровождающей
документации её необходимо рассматривать как неотъемлемую часть
процесса разработки программного обеспечения. Для этого необходима
сложная систематизированная работа по планированию и реализации
документирования
эксплуатации
автоматизированных
систем,
что
регламентируется установленными стандартами.
Следует отметить, что в Советском Союзе, а затем в Российской
Федерации, создание программного обеспечения первоначально, в 70-е годы
прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой
системы программной документации – серии ГОСТ 19.ХХХ19). Они
былиориентированы на класс относительно простых программ малого
объема, создаваемых отдельными программистами. Сейчас эти стандарты
устарели как концептуально, так и по форме, их сроки действия можно
считать законченными и их использование нецелесообразно.
В наше время актуален комплекс стандартов на автоматизированные
системы — основополагающий набор нормативно-технических документов
для всех отечественных системных интеграторов. Практически все работы по
ГОСТ 19.xxx. – URL: http://www.rugost.com/index.php?option=com_content&task=catego
ry§ionid=6&id=19&Itemid=50 (дата обращения 26.05.2018).
19
23
созданию автоматизированных систем для государственного и крупного
коммерческого заказчика в нашей стране сопровождаются выпуском
технической документации в соответствии с этим комплексом, определяемых
в следующих стандартах: ГОСТ 34.601-90 «Информационная технология.
Комплекс стандартов на автоматизированные системы. Стадии создания»20,
ГОСТ
34.603-92
«Информационная
автоматизированных
технология.
систем»21,
Комплекс
стандартов
технология.
ГОСТ
на
34.602-89
Виды
испытаний
«Информационная
автоматизированные
системы.
Техническое задание на создание автоматизированной системы»22 и РД 5034.698-90
«Методические
указания.
Информационная
технология.
Автоматизированные системы. Требования к содержанию документов»23.
Исключительное
значение
для
определения
требований
к
документации имеет ГОСТ 34.602-89, который устанавливает состав,
содержание, правила оформления документа «Техническое задание на
создание системы».
ГОСТ 34.601-90 подразделяет процесс на стандартные стадии, которые
сопровождаются выпуском определённых документов.
В табл. 1 перечислены наиболее распространенные из них.
ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на
автоматизированные
системы.
Стадии
создания».
–
URL:
http://www.rugost.com/index.php?option=com_content&view=article&id=95&catid=22&Itemid
=53 (дата обращения 26.05.2018).
21
ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных
систем».
–
URL:
http://www.rugost.com/index.php?option=com_content&task=view&
id=95&Itemid=53 (дата обращения 26.05.2018).
22
ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание автоматизированной
системы» . – URL: http://www.rugost.com/index.php?option=com_content&view=article
&id=96&catid=22&Itemid=53 (дата обращения 26.05.2018).
23
РД 50-34.698-90 «Методические указания. Информационная технология.
Автоматизированные системы. Требования к содержанию документов» . – URL:
http://www.rugost.com/index.php?option=com_content&view=article&id=98:50-3469890&catid=22&Itemid=53 (дата обращения 26.05.2018).
20
24
Таблица 1. Стадии создания автоматизированных систем
Стадии
Этапы работ
1.1. Обследование объекта и обоснование необходимости
1.Формирование
требований к АС
создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на
разработку АС (тактико-технического задания)
2.1. Изучение объекта.
2.2. Проведение необходимых научно-исследовательских
2. Разработка концепции работ.
АС
2.3. Разработка вариантов концепции АС, удовлетворяющих
требованиям пользователя.
2.4. Оформление отчёта о выполненной работе.
3. Техническое задание
3.1. Разработка и утверждение технического задания на
создание АС.
4.1. Разработка предварительных проектных решений по
4. Эскизный проект
системе и её частям.
4.2. Разработка документации на АС и её части.
5.1. Разработка проектных решений по системе и её частям.
5.2. Разработка документации на АС и её части.
5.3. Разработка и оформление документации на поставку
5. Технический проект
изделий для комплектования АС и (или) технических
требований (технических заданий) на их разработку.
5.4. Разработка заданий на проектирование в смежных частях
проекта объекта автоматизации.
6. Рабочая документация
6.1. Разработка рабочей документации на систему и её части.
6.2. Разработка или адаптация программ.
7.1. Подготовка объекта автоматизации к вводу АС в
действие.
7. Ввод в действие
7.2. Подготовка персонала.
7.3.
Комплектация
АС
поставляемыми
изделиями
(программными и техническими средствами, программно-
25
техническими комплексами, информационными изделиями).
7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы.
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний.
8.1. Выполнение работ в соответствии с гарантийными
8. Сопровождение АС
обязательствами.
8.2. Послегарантийное обслуживание.
Стандарт
ГОСТ
34.603-92
устанавливает
последовательность
испытаний готовой информационной системы, цели и результаты испытаний.
Выделяется 3 типа испытаний: предварительные испытания, состоящие из
автономных
и
комплексных,
опытная
эксплуатация
и
приемочные
испытания. Задачей испытаний является выявление качества выполнений
функций программных средств, проверка навыков персонала, необходимых
для
работы
с
эксплуатационной
автоматизированной
документации,
системой,
определение
представление
полноты
характеристики
информационной системы в целом в соответствии с техническим заданием. В
табл. 2 указан состав испытаний на каждом этапе.
Таблица 2. Типы испытаний
Предварительные испытания
Цели
Определение работоспособности информационной системы и решение
вопроса о возможности приемки информационной системы в опытную
эксплуатацию
Автономные
Условия
После проведения разработчиком отладки и тестирования поставляемых
программных и технических средств системы и предоставления им
соответствующих документов об их готовности к испытаниям, а так же
после ознакомления персонала с эксплуатационной документацией
26
Программа
-перечень функций информационной системы, подлежащих испытаниям;
испытаний
-описание
взаимосвязей
объекта
испытаний
с
другими
частями
информационной системы;
-условия, порядок и методы проведения испытаний и обработки
результатов;
- график проведения испытаний;
-критерии приемки частей по результатам испытаний.
Результатная
Протокол испытаний с заключением о возможности допуска части
информация
информационной системы к комплексным испытаниям
Комплексные
Программа
- перечень объектов испытания:
испытаний
- состав предъявляемой документации;
- описание проверяемых взаимосвязей между объектами испытаний;
- очерёдность испытаний частей информационной системы;
- порядок и методы испытаний, в том числе состав программных средств
и оборудования, необходимых для проведения испытаний, включая
специальные стенды и полигоны.
Результатная
- протокол комплексных испытаний;
информация
- акт приемки в опытную эксплуатацию.
Опытная эксплуатация
Цели
- определение фактических значений количественных и качественных
характеристик
-
определение
информационной
готовности
персонала
к
системы;
работе
в
условиях
функционирования информационной системы;
- определение фактической эффективности информационной системы;
- корректировка документации.
Условия
- акт о приемке информационной системы в опытную эксплуатацию;
- приказ заказчика о начала опытной эксплуатации, согласованный с
разработчиком.
Программа
- условия и порядок функционирования информационной системы;
испытаний
- порядок проверки технических средств;
- продолжительность опытной эксплуатации, достаточную для проверки
правильности функционирования информационной системы;
27
- порядок устранения недостатков, выявленных в процессе опытной
эксплуатации.
Результатная
- рабочий журнал;
информация
- акт о допуске информационной системы к приемочным испытаниям;
-
дополнение
к
техническому
заданию
в
случае
выявления
нереализованных требований.
Приемочные испытания
Цели
- определение соответствия информационной системы техническому
заданию;
- оценка качества опытной эксплуатации;
- решение вопроса о возможности приемки информационной системы в
постоянную эксплуатацию.
Условия
- техническое задание информационной системы;
- акт приёмки в опытную эксплуатацию;
- рабочие журналы опытной эксплуатации;
- акт завершения опытной эксплуатации и допуска ИС к приемочным
испытаниям;
Программа и методика приёмных испытаний.
Программа
- перечень объектов, выделенных в системе для испытаний и перечень
испытаний
требований, которым должны соответствовать объекты;
- критерии приемки системы и ее частей;
- условия и сроки проведения испытаний;
- средства для проведения испытаний;
- перечень лиц, ответственных за проведение испытаний;
- перечень оформляемой документации.
Результатная
- объединённый протокол испытаний объектов;
информация
- акт о приемке системы в постоянную эксплуатацию.
Методические
указания
руководящего
документа
50-34.698-90
«Автоматизированные системы. Требования к содержанию документов»
распространяются
на
автоматизированные
системы,
используемые
в
различных сферах деятельности, включая их сочетание, и устанавливают
28
требования к содержанию документов, разрабатываемых при создании
информационных систем24.
Данный комплекс включает в себя:
требования к содержанию документов по общесистемным
решениям;
требования
к
содержанию
документов
с
решениями
по
содержанию
документов
с
решениями
по
содержанию
документов
с
решениями
по
содержанию
документов
с
решениями
по
документов
с
решениями
по
организационному обеспечению;
требования
к
программному обеспечению;
требования
к
техническому обеспечению;
требования
к
информационному обеспечению;
требования
к
содержанию
математическому обеспечению;
Содержание документов, разрабатываемых на предпроектных
стадиях;
содержание распорядительных документов.
Также стоит отметить регламенты, установленные международной
организация по стандартизации25, например стандарт ИСО/МЭК 15910-2002
«Информационная
технология.
Процесс
создания
документации
пользователя программного средства»26 является наиболее современным
РД
50-34.698-90
«Методические
указания.
Информационная
технология.
Автоматизированные системы. Требования к содержанию документов» . – URL:
http://www.rugost.com/index.php?option=com_content&view=article&id=98:50-3469890&catid=22&Itemid=53 (дата обращения 26.05.2018).
25
Международная организация по стандартизации, ИСО (International Organization for
Standardization, ISO) — международная организация, занимающаяся выпуском стандартов. –
URL: https://ru.wikipedia.org/wiki/Международная_организация_по_стандартизации#cite_notegeneral_vocabulary-1 (дата обращения 26.05.2018).
26
ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания
документации пользователя программного средства». – URL: http://www.rugost.com/
24
29
нормативным документом, который регламентирует процессы создания
эксплуатационной
документации
автоматизированных
информационных
традиционной
схеме
для
стандартов
конечных
систем.
пользователей
Стандарт
международной
основан
организации
на
по
стандартизации: первые семь разделов вводные и определяют терминологию.
Основное содержание стандарта сосредоточено в 8 разделе «Требования к
документированию программного средства».
Первый
средств»
подраздел
устанавливают
«Процессы
общую
документирования
схему
процессов
и
программных
их
правила
взаимодействия между собой. Тут же описан план документирования
системы для
разработчиков сопроводительных документов, и процедуры
контроля выполнения плана.
Второй подраздел посвящен требованиям к содержанию типовой
спецификации. В нём указаны требования к языку и грамматике составления
сопроводительных документов, к оформлению текста, графических рисунков
и таблиц, а также требования к бумаге. Раздел подробно регламентирует
технические правила оформления твердой копии документов и правила
структурирования
и
представления
схем
компонентов,
окружения,
иллюстраций и основного текста документов.
Специальный
подраздел
посвящен
подготовке
электронных
документов, в нём регламентируется общая схема, размещение материала и
комментариев, помощь подсказками и навигация по тексту.
Стандарт
представляет
разработчикам
документации
способ
определения и применения процесса документирования при создании
автоматизированных систем. Основной работой, регламентируемой эти
стандартом, является разработка комплексного плана документирования,
который обеспечит более качественный пакет документов, сопровождающий
index.php?option=com_content&view=article&id=102:15910-2002&catid=22&Itemid=53 (дата
обращения 26.05.2018).
30
программный продукт. Стандарт описывает информацию, необходимую
разработчику документации для проверки и распространения документов от
заказчика.
Данный
стандарт
определяет
реализацию
процесса
документирования и может быть адаптирован к условиям конкретных
проектов. Он не определяет структуру конкретного документа, его
содержание и другие аспекты комплектности, однако он устанавливает метод
планирования и проведения процессов документирования.
Вторым
стандартом
данной
организации,
который
необходимо
рассмотреть, является ИСО 9127-94 «Системы обработки информации.
Документация пользователя и информация на упаковке для потребительских
программных пакетов»27. Он применяется при создании пользовательской
документации на коммерческие пакеты разработанных программных
средств,
поставляемых
на
рынок.
Пользовательская
и
рекламная
документация должна включать общие сведения о продукте, введение,
ограничения
эксплуатации
и
область
применения.
Инструкция
по
эксплуатации программного средства должна содержать описание, в котором
заключена вся информация, необходимая пользователю для инсталляции,
запуска и эксплуатации автоматизированных систем. Эта документация
представляет
собой
одно
или
несколько
руководств
пользователя,
поставляемых вместе с носителями программных продуктов в коммерческом
пакете, так пользователи не могут ознакомиться с подробным руководством
до покупки продукта. Описание задач и области применения программного
обеспечения публикуется на наружной упаковке коммерческого пакета. Его
задача дать возможность потенциальному покупателю оценить возможности
продукта к своим потребностям.
ГОСТ Р ИСО 9127-94 «Системы обработки информации. Документация пользователя и
информация на упаковке для потребительских программных пакетов». – URL:
http://docs.cntd.ru/document/gost-r-iso-9127-94 (дата обращения 26.05.2018).
27
31
Стандарт института инженеров электротехники и электроники28 IEEE
1063-2001 «Документация программного обеспечения для пользователя»29
указывает
общие
программные
требования
продукты
к эксплуатационной
широкого
применения.
документации
Стандарт
на
определяет
минимальные требования к форме и содержанию комплекта документов для
пользователей
документы,
программных
применяемые
продуктов.
при
Стандарт
внедрении,
ориентирован
эксплуатации
и
на
поставке
автоматизированных систем любого размера и назначения, но без изменения
и сопровождения программ.
Он не применим для технологической документации, используемой
разработчиком,
а
также
для
оформления
коммерческих
пакетов.
Использование стандарта не должно препятствует более точных требований
к документации, а также внутренних стандартов предприятия по стилю
подачи информации в документах.
В первых двух частях стандарта представлено введение, описывающее
назначение, ограничения для применения и определения основных терминов.
В третьем разделе определяется структура разработки эксплуатационной
документации:
определение
потенциальных
пользователей
программного
обеспечения и методов их взаимодействия с документами;
определение комплектации и ориентации каждого документа на
конкретную область применения;
определение
способов
использования
документов
–
инструктивных для обучения применению и основным операциям по
использованию, диагностике и внедрению программных средств или
Институт инженеров электротехники и электроники — IEEE (англ. Institute of Electrical
and Electronics Engineers). Это международная некоммерческая ассоциация специалистов в
области техники, мировой лидер в области разработки стандартов по радиоэлектронике,
электротехнике и аппаратному обеспечению вычислительных систем и сетей.
29
IEEE 1063-2001 – IEEE Standard for Software User Documentation. – URL:
http://standards.ieee.org/findstds/standard/1063-2001.html (дата обращения 26.05.2018).
28
32
справочных, детально представляющих всю необходимую информацию при
эксплуатации и функционировании систем.
В четвертом разделе представлены требования к структуре формы
единого пользовательского документа. В одной части раздела перечислены
названия подразделов пользовательского
документа, а вторая
часть
посвящена составу этих подразделов.
Пятый раздел посвящен требованиям и рекомендациям к содержанию
подразделов пользовательского документа на автоматизированную систему.
Шестой раздел представляет собой общие методические требования к
представлению документа пользователя, включающие в себя методику
пояснения материала, рекомендации по составу и формату текста,
терминологические рекомендации, а также по отражению взаимосвязи частей
материала.
Документирование разработки и внедрения является неотъемлемой
частью работы по реализации проекта создания автоматизированных систем.
Правильно
организованное
документирование
качество самого программного продукта
обеспечивает
высокое
и сокращает трудозатраты
разработки за счёт того, что позволяет отслеживать статус работ, выявлять
риски,
а
также
установить
и
систематизировать
взаимоотношения
разработчиков с заказчиком и взаимоотношения между подразделениями
внутри компании. Для корректного ведения документации, сопровождающей
разработку
программного
обеспечения,
организации-разработчику
необходимо назначить лиц, ответственных за составление документов на
программное обеспечение,
спроектировать
систему
разрабатываемое организацией, а также
документирования
разработки
и
внедрения
автоматизированных систем в организации, состоящую из форм документов
и
методических
рекомендаций
к
их
заполнению,
основанные
на
установленных государственных стандартах России и международных
организаций стандартизации.
33
ГЛАВА 2. ДОКУМЕНТАЦИОННОЕ ОБЕСПЕЧЕНИЕ ВНЕДРЕНИЯ
ДЕЙСТВУЮЩИХ АВТОМАТИЗИРОВАННЫХ СИСТЕМ «ДЖУС
ДЕВЕЛОПМЕНТ»
§ 1. ООО «Джус Девелопмент» как разработчик программного
обеспечения
Общество с ограниченной ответственностью «Джус Девелопмент»
является коммерческой организацией, созданной для получения прибыли и
насыщения рынка товарами и услугами в сфере разработки программных
продуктов.
Компания ООО «Джус Девелопмент» была образована в январе 2017
года, в результате разделения общества с ограниченной ответственностью
«ГЕКЛ» на две огранизации ООО «ГЕКЛ» и ООО «Джус Девелопмент».
Компания ООО «ГЕКЛ» - лидер на рынке SMM продвижения в России,
одним из проектов которой является сеть сообществ «Бесплатный» в
социальной сети Вконтакте, насчитывающая суммарную аудиторию более
13 млн. человек и состоящая из 236 сообществ. В 2016 г. штатные
специалисты рекламной компании самостоятельно спроектировали и
разработали собственную CMS-систему (Система управления контентом от
англ. Content management system, CMS - информационная система или
компьютерная программа, используемая для обеспечения и организации
совместного процесса создания, редактирования и управления содержимым,
иначе — контентом (от английского content)30, названную Juice, аналоги
30
Савельева Н. Системы управления контентом // Открытые системы. — 2004. — № 4. –
С. 25.
34
которой на данный момент в сфере работы с B2B31 клиентами отсутствуют.
Система полностью отвечает требованиям к основным функциям CMS:
предоставление
инструментов
для
создания
содержимого,
организация совместной работы над содержимым;
управление
содержимым:
хранение,
контроль
версий,
соблюдение режима доступа, управление потоком документов и т. п.;
публикация содержимого;
представление информации в виде, удобном для навигации,
поиска32.
Данная система позволяет привлекать потенциальных клиентов прямо
на сайте, а также в значительной степени автоматизирует работу
менеджеров, что позволяет сократить штат сотрудников и перераспределить
расходы компании на инвестирование или другие нужды. В результате
успешного внедрения программного продукта в ООО «ГЕКЛ» для
успешного продвижения новой CMS-системы на рынке была открыта
компания, специализирующаяся на разработке программного обеспечения и
корпоративных сайтов ООО «Джус Девелопмент».
Основным предметом деятельности общества является разработка
программного обеспечения, web-сайтов, корпоративных информационных
систем и их внедрение в организации. Второстепенной деятельностью
общества является таргетированная реклама в социальных сетях на
территории Российской Федерации и стран СНГ в сети сообществ,
принадлежащей ООО «ГЕКЛ». Так же организация занимается поддержкой
внедрённых продуктов и маркетингом в социальных сетях для них.
Общая численность работников организации составляет 12 человек.
Руководство
обществом
осуществляет
генеральный
директор 33.
B2B – англ. «Business to business» — рус. «бизнес для бизнеса», сокращённо произносится
– «би ту би». – URL: https://ru.wikipedia.org/wiki/B2B (дата обращения 26.05.2018).
32
Денис Колисниченко. Движок для вашего сайта. CMS Joomla!, Slaed, PHP-Nuke. – СПб.,
2008. – С. 176.
31
35
Генеральный директор имеет в подчинении финансового и технического
директоров.
Генеральный директор предупреждает возможные риски на данном
рынке и строит долгосрочные перспективы развития проектов организации.
Финансовый
директор
осуществляет
потоками и рисками, финансовое
определяет
финансовую
осуществляет
меры
по
управление
финансовыми
планирование и отчётность. Он
политику
организации,
обеспечению
её
разрабатывает
финансовой
и
устойчивости.
Руководит работой по управлению финансами исходя из стратегических
целей и перспектив развития организации, по определению источников
финансирования с учётом рыночной конъюнктуры.
Технический
директор
технических
систем,
обеспечение
рационального
обеспечивает
координирование
бесперебойную
работы
использования
персонала,
работу
учет
и
материально-технических
ресурсов.
В штат сотрудников так же входит сотрудники отдела продаж,
ведущие переговоры с клиентами, а так же осуществляющие поддержку
внедрённых продуктов.
Бухгалтерский учет на предприятии - важнейшее звено формирования
экономической политики, инструмент бизнеса, один из главных механизмов
управления
производством
совершенствованию
и
сбытом
организации
продукции.
производства,
Он
способствует
оперативного
и
долгосрочного планирования, прогнозирования и анализа хозяйственной
деятельности. На основе бухгалтерского анализа может быть определена
тенденция развития предприятия. За бухгалтерский учет в организации
отвечает главный бухгалтер, подчиняющийся финансовому директору.
Из работающих в настоящее время в организации сотрудников –
только
33
один
секретарь-референт
Устав Общества… C. 3-4.
выполняет
функции,
связанные
с
36
документационным обеспечением. Он строит свою работу на основании
должностной
инструкции
секретаря-референта,
утвержденной
в
организации, и инструкции по ведению делопроизводства в организации.
Согласно должностной инструкции секретаря-референта на секретаряреферента возлагаются следующие функции:
организационное
и
документационное
обеспечение
управленческой деятельности организации;
координация работы офиса;
осуществление методического руководства и контроля за
ведением делопроизводства в организации;
оперативно-организационное
обслуживание
деятельности
организации;
подготовка, оформление документации по личному составу, ее
учет и хранение;
совершенствование системы документооборота в организации;
координация и контроль за соблюдением установленного
порядка работы с документами.
Часть делопроизводственных процессов, как и в большинстве
современных организаций, автоматизированы. Это, в первую очередь,
наличие на каждом рабочем месте компьютера и локальной сети, благодаря
которой документы могут быстро поступать на исполнение. Это также
наличие современной оргтехники, позволяющей быстро и качественно
производить те или иные работы: копирование документов, сканирование и
др.; наличие электронной почты и факса, позволяющее быстро передавать и
получать информацию из других организаций.
Особенностью данной организации являются уникальные проекты в
сфере
разработки
программного
обеспечения
для
коммерческих
организаций и предоставление специфических услуг на рынке рекламы, не
развитых в полной мере на территории Российской Федерации. Рекламная
37
часть компании является самой крупной и наиболее развитой среди
подобных
и
единственная
имеет
собственную
федеральную
сеть
крупнейших рекламных площадок, не занимаясь их арендой. Несмотря на
то,
что
свою
основную
деятельность
общество
с
ограниченной
ответственностью «Джус Девелопмент» ведёт не более года, у неё уже
выполнено двенадцать проектов на разработку и три из пяти текущих на
финальной стадии работ.
Данная
организация
состоит
из
команды
молодых
квалифицированных специалистов Белгорода, поддерживает качество
предоставляемых услуг на международном уровне.
§2. Характеристика JUICE-CRM
Система управления взаимоотношениями с клиентами CRM —
прикладное
программное
обеспечение
для
организаций,
предназначенное для автоматизации стратегий взаимодействия с
заказчиками, в частности для повышения уровня продаж, оптимизации
маркетинга и улучшения обслуживания клиентов путём сохранения
информации о клиентах и истории взаимоотношений с ними,
установления и улучшения бизнес-процессов и последующего анализа
результатов34.
Основными
задачами
внедрения
CRM
является
повышение
лояльности клиентов, используя анализ накопленной информации о них,
оптимизация
ценовой
политики,
а
также
настройка
инструментов
продвижения услуг и товаров.
Основными функции Juice CRM являются:
Система управления взаимоотношениями с клиентами (CRM, CRM-система,
сокращение
от
англ.
Customer
Relationship
Management).
–
URL:
https://ru.wikipedia.org/wiki/Система_управления_взаимоотношениями_с_клиентами (дата
обращения 26.05.2018).
34
38
инструменты создания контента для публикаций, организация
совместной работы над содержимым сайта, склада;
управление
контентом,
его
хранение,
контроль
версий,
соблюдение режима доступа, управление потоком документов, контроль
графика работы, бухгалтерские выписки, интеграция с 1С;
публикация контента на сайте заказчика, в социальных сетях и
периодических изданиях;
представление информации в удобном виде для навигации и
управления;
фронтальная часть, обеспечивающая обслуживание клиентов на
точках продаж с автономной, распределенной или централизованной
обработкой информации из базы данных;
операционная часть, обеспечивающая авторизацию операций и
оперативную отчётность для руководящего звена компании, менеджеров и
маркетологов;
хранилище данных для быстрого и удобного доступа, с
возможностью легкой сортировки и сегментации;
аналитики,
аналитическая
которые
подсистема
потребуются
для
проведения
сотрудникам,
от
любых
видов
бухгалтерии
до
маркетинговых цепочек.
интеграция с социальными сетями с целью привлечения
трафика, обработки и воздействия на новых клиентов компании, занесенных
в базу данных;
аналитика количества заказов по времени и часовым поясам для
построения правильной модели графика работы компании;
отслеживание
количества
взаимодействий
потенциальных
клиентов с компанией;
составление документов, счетов, отчетов и выписок в режиме
онлайн или по запросу менеджера.
39
Системные требования программного продукта представлены в табл.
3.
Таблица 3. Системные требования Juice-CRM
Веб-браузер
Internet Explorer 7.0 и выше, или Firefox 3.5
и выше, или Opera 9.5 и выше, или Safari
3.2.1 и выше, или Chrome 2 и выше
Север
Debian 7.2 (x86_64)
Процессор
2 CPU, 4 GB Ram и выше
Система управления сервером
Панель ISP Manager Lite 5 и выше;
Веб-сервер
Apache
Командная строка
Модуль cURL
Место на жёстком диске
Не менее 40 ГБ свободного места
Система написана на языке программирования PHP35, версии 7.1. Это
язык общего назначения, интенсивно применяемый для разработки вебприложений. В настоящее время поддерживается большинством сетевых
систем
и
является
лидером
среди
языков
программирования,
применяющихся для создания веб-сайтов. Для интеграции с социальными
сетями
и
другими
сторонними
ресурсами
Juice-CRM
применяет
программный интерфейс приложения API36 - набор готовых программных
решений
для
интеграции
с
другими
ресурсами,
предоставляемый
разработчиками системы для внедрения в неё.
Самой важной частью подобной системы является база данных. Базой
данных Juice-CRM управляет система управления базой данных MySQL
версии 5.5.47.
PHP (Hypertext Preprocessor — «PHP: препроцессор гипертекста». – URL:
https://ru.wikipedia.org/wiki/PHP (дата обращения 26.05.2018).
36
API (программный
интерфейс
приложения,
интерфейс прикладного
программирования)
application programming interface, API)
.
–
URL:
https://ru.wikipedia.org/wiki/API (дата обращения 26.05.2018).
35
40
MySQL - это быстрая, надежная, открыто распространяемая СУБД.
MySQL, как и многие другие СУБД, функционирует по
модели
«клиент/сервер». Сетевая архитектура, в которой устройства выполняют
роли клиентов либо серверов37.
Интерфейс администрирования предствлен phpMyAdmin 4 – наиболее
удобный интерфейс для управления базами данных на языке SQL38. Данный
интерфейс предоставляет широкий спектр функций и является бесплатным,
что делает его доступным любому разработчику.
Juice-CRM является довольно безопасной и защищённой системой,
она уже включает возможности защиты от наиболее распространенных
угроз: XSS39 уязвимости (тип атаки, целью которого является внедрить на
страницу вредоносный код и выполнить его на компьютере пользователя
при открытии им этой страницы), межсайтовая подделка запроса, также
известен как СSRF40 (вид атак на посетителей веб-сайтов, использующий
недостатки протокола HTTP), а также brute-force атак41 (подбор пароля с
помощью перебора до тех пор, пока он не будет найден). Используя
Казаков Б. В. Основы работы в MySQL.– Пенза, 2012. С. 4.
SQL (англ. structured query language — «язык структурированных запросов») —
декларативный язык программирования, применяемый для создания, модификации и
управления данными в реляционной базе данных, управляемой соответствующей
системой управления базами данных. – URL: https://ru.wikipedia.org/wiki/SQL (дата
обращения 26.05.2018).
39
XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — тип атаки на вебсистемы, заключающийся во внедрении в выдаваемую веб-системой страницу
вредоносного кода (который будет выполнен на компьютере пользователя при открытии
им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника.
Является
разновидностью
атаки
«внедрение
кода».
–
URL:
https://ru.wikipedia.org/wiki/Межсайтовый_скриптинг (дата обращения 26.05.2018).
40
CSRF (англ. Сross Site Request Forgery — «межсайтовая подделка запроса», также
известна как CSRF) — вид атак на посетителей веб-сайтов, использующий недостатки
протокола HTTP. – URL: https://ru.wikipedia.org/wiki/Межсайтовая_подделка_запроса
(дата обращения 26.05.2018).
41
Полный перебор (или метод «грубой силы», англ. brute force) — метод решения
математических задач. Относится к классу методов поиска решения исчерпыванием
всевозможных вариантов. Сложность полного перебора зависит от количества всех
возможных решений задачи. Если пространство решений очень велико, то полный
перебор может не дать результатов в течение нескольких лет или даже столетий. – URL:
https://ru.wikipedia.org/wiki/Полный_перебор (дата обращения 26.05.2018).
37
38
41
совокупность современных методов защиты можно не переживать о
внедрении опасного кода (SQL injection) в проект.
На текущий момент рынок автоматизированных систем довольно
насыщен, наиболее популярными конкурентами Juice-CRM являются
Microsoft Dynamics CRM, 1C:CRM и Bitrix CRM.
Microsoft Dynamics CRM пользуется большой популярностью в
крупных компаниях. Она максимально приближена к среде разработке, что
расширяет
её
функциональные
возможности,
но
усложняет
её
использование, так как перед началом работы её необходимо настроить
процессы взаимодействия с системой, что займёт много времени. Ещё
одним минусом данного продукта является цена, она начинается от 7185
рублей в месяц за одного подключенного пользователя. Интерфейс системы
представлен на рис. 1.
Рис. 1. Интерфейс Microsoft Dynamics CRM
42
Система 1С:CRM работает на основе ресурсов 1С:Предприятие. Ее
использование автоматизирует процесс сбора и анализа показателей продаж
в наиболее распространённой системе управления бизнесом на территории
России. Особенность системы – возможность отслеживать продажи
крупного ассортимента товаров, реализуемых компанией. Минусами
данного программного обеспечения является завышенная цена для крупного
бизнеса, стоимость для крупной организации составит 19900 рублей, в то
время когда индивидуальные предприниматели могут начать работу с
1С:CRM за 6900 рублей. Также минусом является невозможность
использования данного продукта без ведения работы в приложении
1С:Предриятие.
Интерфейс данного продукта представлен на рис. 2.
Рис. 2. Интерфейс 1С:CRM
Bitrix CRM является самой доступной и распространённой системой
на рынке. Её плюсом является пакет дополнительных функций, например
виртуальная
автоматическая
телефонная
станция,
позволяющая
43
осуществлять звонки прямо из системы. У данной системы есть мобильная
версия, что делает её ещё более удобной. Система позволяет создать
своеобразную корпоративную социальную сеть, в которой возможно
общение
и
обсуждение
проектов
с
любыми
сотрудниками.
Её
распространённость обусловлена тем, что она бесплатна для компаний
малого бизнеса, среди которых сначала стала популярна среда разработки
веб-сайтов для продаж товаров по интернету Bitrix Framework, более
ранний продукт компании. Данная версия позволяет подключить бесплатно
12 сотрудников. Интерфейс данного ресурса показан на рис. 3.
Рис. 3. Интерфейс Bitrix CRM
Juice-CRM объединяет в себе все положительные качества указанных
систем, попутно решая проблемы, которые были определены как минусы.
Так стоимость минимальной комплектации автоматизированной
системы начинается от 90000 рублей за неограниченное количество
пользователем с передачей разработанного продукта заказчику, данный
продукт не нуждается в поддержке, за исключением гарантийных случаев.
44
Компания-заказчик может выбрать дополнительные блоки функций из
предложенных или заказать разработку новых. Подобная политика
позволяет получить систему, не нагруженную ненужными процессами,
содержащую ещё и уникальные функции, которые не может предложить ни
одна из систем на рынке CRM в России. Разработчик бесплатно
поддерживает
продукт
первые
6
месяцев
с
момента
введения
в
эксплуатацию, предоставляя подробные инструкции на каждый из модулей
системы,
а
также
осуществляя
круглосуточную
консультацию
администраторов внедрённых систем, назначенных заказчиком проекта.
Интерфейс одной из версий Juice-CRM показан на рис. 4.
Рис. 4. Интерфейс Juice-CRM
Программное
средство
Juice-CRM
разработки
ООО
«Джус
Девелопмент» имеет ряд преимуществ перед своими конкурентами, такими
как относительная дешевизна при условии долгосрочных перспектив, а
также модульности, адаптивности и автономности системы от поставщика
программного обеспечения после введения в эксплуатацию. Довольно
45
лояльные системные требования делают возможным использование
системы на простом оборудовании, что не вынуждает заказчика тратить
крупные бюджеты на закупку техники для обеспечения работы системы.
Современные технологии в разработки позволяют системе и постоянно
развиваться и закрепить за собой актуальность на рынке.
§3. Анализ оформления документов, связанных с обеспечением
деятельности программного продукта
Для реализации решений проблем документирования, описанных в
первой главе, в проектах создания автоматизированных систем средств
необходимы организационные мероприятия, гарантирующие сторонам
разработки определенную
культуру,
дисциплину проектирования
и
использования документов. Такая система должна будет обеспечивать
специалистам разной квалификации и роли, возможность взаимодействия
между
собой
информацией
при
о
решении
статусе
комплексных
разработки
задач
и
для
управления
изменениях
проекта.
Регламентируемая информация, содержащаяся в документах, повысит
ответственность специалистов за её корректность заполнения, сократит
время на её форматирование, а также улучшит качество её реализацию в
жизненном цикле разработки.
На данный момент компанией ООО «Джус Девеломпент» в
жизненном цикле автоматизированной системы применяются следующие
сопроводительные документы:
1)
контракт на выполнение работ по созданию программного
продукта, определяющий обязанности сторон;
2)
техническое задание на разработку, описывающее требования к
программному средству;
3)
задание на разработку, содержащее перечень работ;
46
отчет о перечне работ, используемый для информирования
4)
заказчика о статусе разработки, перечне выполненных задач проекта;
спецификация, описывающая принцип работы программного
5)
продукта;
6)
текст программ, описывающий функции системы;
7)
каталог базы данных, отображающий структуру потока данных
в системе;
8)
протокол испытаний, содержащий
результаты
испытаний
системы на разных этапах;
9)
акт приемки системы, подтверждающий ввод в эксплуатацию;
10)
акт завершения работ, завершающий разработку программы;
11)
задание на доработку, позволяющее после сдачи проекта
вносить изменения в продукт.
Данного комплекса документов, сопровождающих проект на всех
этапах
жизненного
цикла,
достаточно
для
исполнителя,
команда
разработчиков системы и документации которого состоит из нескольких
программистов и менеджера, выделенных для одного проекта.
Ранее в работе была отмечена важность корректного заполнения
документов
теологической
документации,
обусловленная
экономией
ресурсов, выделенных на разработку, а также соблюдение сроков сдачи
проекта. В качестве примера мы рассмотрим текущую форму документа
«Техническое
Задание»,
выделим
его
недостатки,
определим
несоответствие документа стандарту, регламентирующему структуру и
содержания подобной документации.
Структура технического задания программного продукта Juice-CRM
состоит из следующих разделов:
1)
термины и определения;
2)
общие сведения, включающие в себя:
назначение документа;
47
наименование исполнителя и заказчика;
краткие сведения о компании;
основание для разработки сайта;
плановые сроки начала и окончания работ по создаю сайта;
порядок оформления и предъявления результатов работ;
3)
основные требования к сайту:
требования к сайту;
требования к разграничению доступа;
4)
разделы сайта, включает в себя описание компонентов системы
и их взаимосвязи;
5)
требованиям к видам обеспечения:
требования к программному обеспечению;
требования к аппаратному обеспечению;
6)
Состав работ по созданию сайта, состоящий из задач, которые
необходимо выполнить в процессе разработки автоматизированной
системы.
Данная структура не соответствует требованиям, предъявляемым к
техническим
заданиям
согласно
государственным
стандартам,
информация,
содержащаяся в документе, неправильно распределена
между разделами, отсутствуют важные разделы, определяющие этапы
разработки программного обеспечения и сопроводительной документации.
В техническом задании отсутствуют характеристика подразделения,
подлежащего автоматизации, перечень документов, сопровождающих
автоматизированную систему, а источники разработки. Также отсутствует
раздел, определяющий требования к документированию разработки и
внедрения программного продукта.
Необходимо конкретизировать требования к продукту за счёт ввода
новых пунктов в раздел «Требования к системе», описать прочие
требования,
помимо
требований
к
программному
и
техническому
48
обеспечению,
такие
информационному,
как
требования
к
лингвистическому,
математическому,
метрологическому,
организационному и методическому обеспечению системы.
Для унификации формы требуется заменить упоминание типа
системы из названия раздела, заменив «сайт» на «автоматизированная
система» или «программное средство».
Несоответствие
используемой
формы
документа
описанным
стандартом обуславливает потребность в разработке новой структуры
технического задания. Также следует отметить отсутствие
эксплуатационной
сопровождающей
документации
для
автоматизированную
конечного
систему,
в
какой-либо
пользователя,
связи
с
чем
предлагается разработать паспорт на программное средство, который
будет включён в коммерческий пакет, поставляемый заказчику при
покупке системы.
Эти документы войдут в комплекс документов, включённых в
систему документирования разработки и внедрения автоматизированной
системы компании ООО «Джус Девеломпент», их структура будет описана
в третьей главе.
49
ГЛАВА 3. РАЗРАБОТКА СИСТЕМЫ ДОКУМЕНТИРОВАНИЯ
РАЗРАБОТКИ И ВНЕДРЕНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
§ 1. Проектирование унифицированной формы технического задания
на разработку автоматизированной системы
В первую очередь, необходимо рассмотреть основные реквизиты и
требования, предъявляемые к техническому заданию.
Титульная страница оформляется на бумаге формата А4. Согласно
ГОСТу Р 7.0.97-2016. «Национальный стандарт Российской Федерации.
Система стандартов по информации, библиотечному и издательскому
делу. Организационно-распорядительная документация. Требования к
оформлению документов»42 наименование организации, разработавшей
документ в шапке сайта, гриф согласования слева и гриф утверждения
справа под шапкой документа. Следом указывается название документа, в
данном
случае
«Техническое
разрабатываемой
задание»,
автоматизированной
а
также
системы.
В
наименование
нижней
части
указывается место и дата составления документа. На титульном листе
размещаются подписи заказчика и исполнителя, которые заверяются
оттиском основной печати, используемой в хозяйственной деятельности
организации.
Подписи
автоматизированной
согласовании
и
исполнителей
системы
и
рассмотрении
его
проекта
заказчиков,
проекта
на
разработку
участвующих
технического
в
задания,
размещаются на последнем листе документа.
Листы нумеруются с первой страницы после титульного листа, в
верхней части страницы, по центру.
ГОСТ Р 7.0.97-2016. «Национальный стандарт Российской Федерации. Система стандартов
по информации, библиотечному и издательскому делу. Организационно-распорядительная
документация. Требования к оформлению документов» . – URL: http://www.consultant.ru/
document/cons_doc_LAW_216461/ (дата обращения 26.05.2018).
42
50
Техническое задание на разработку автоматизированной системы
содержит следующие разделы и подразделы:
1) общие сведения:
название разрабатываемого проекта;
список документов, на основании которых разрабатывается
система, и их характеристики;
реквизиты заказчика и исполнителя проекта на разработку
программного обеспечения;
сроки начала и окончания работ по разработке программы;
информация об источниках финансирования и его порядке;
определение
оформления
и
представления
результатов
выполненных работ на разработку частей системы в рамках проекта
заказчику;
перечень
документов,
использованных
при
разработке
технического задания;
определения, обозначения и сокращения.
Раздел даёт общую характеристику проекта, определяет сроки
реализации, контакты и обязанности сторон. Включает
таблицу
терминов и сокращений, используемых в техническом задании с
пояснениями для доступности понимания документа лицам, не
имеющим отношения к разработке продукта. Главным документом,
являющимся основанием, является контракт между разработчиком и
заказчиком
на
разработку
автоматизированной
системы.
Документами, на основе которых разрабатывается техническое
задание,
является
форма
разрабатываемого
методические рекомендации к ней.
2) Назначение и цели создания системы:
назначение системы;
цели создания системы.
документа
и
51
«Назначение системы» определяет род деятельности, которую
необходимо автоматизировать, и объекты, подверженные автоматизации.
«Цели создания системы» отображают результаты, которые должны быть
достигнуты в результате внедрения автоматизированной системы в
рабочие процессы организации заказчика.
3) Описание объектов, подвергнутых автоматизации:
В этом разделе подробно описывается объект автоматизации, а
также представляется функциональная структура объекта, который
необходимо автоматизировать.
4) Требования к разрабатываемой автоматизированной системе:
общие требования к продукту;
требования
к
основным
функциям
разрабатываемого
приложения;
требования к обеспечению программного средства.
Общие
требования
включает
«Требования
к
структуре
и
функционированию системы», состоящий из перечня подсистем с их
описанием
и
требований
способам
и
средствам
связи
для
информационного обмена между компонентами системы, определяющий
протоколы связи между компонентами. Далее определяется состав
персонала, обеспечивающего работу системы, и его необходимую для
работы
квалификацию,
утверждаются
показатели
назначения,
выполнение которых обозначает соответствие назначению системы.
Требования надёжности включает в себя меры обеспечения надёжности
системы и допустимое время на устранение её отказов. Требования к
безопасности
распространяются
на
серверное
оборудование
в
соответствии с «Правилами устройства электроустановок» и «Правилами
техники
безопасности
потребителей».
поставляемых
Данный
при
пункт
программных
эксплуатации
заполняется
продуктов
электроустановок
одинаково
компании.
для
всех
Требования
к
52
эргономике и эстетике определяют структуру меню управления и
разделов
сайта,
дизайн
окон.
Требования
к
транспортабельности
включают информацию о правилах перемещения программного и
технического обеспечения. Требования к эксплуатации, хранению и
обслуживанию
системы
содержат
описание
условий
содержания
оборудования, на котором установлена система. Далее указывается
список требований к информационной безопасности, сохранению данных
при авариях, требования к защите от влияния внешних воздействий.
Указывается требование соблюдения патентной чистоты. Требования по
стандартизации и унификации описывают методологии, используемые
при разработке, согласно установленным стандартам. В заключающем
пункте требований к структуре указываются дополнительные требования
заказчика к разработке.
Раздел «Требования к функциям» описывает функции системы и
требования к их реализации.
«Требования к видам обеспечения» из 8 пунктов. Требования к
математическому обеспечению включают особенности использования
математических моделей, методов и алгоритмов. К Juice-CRM не
предъявляются. «Требования информационному обеспечению системы»
бактеризуют структуру хранения данных внутри системы, указывает
модель системы данных. «Требования к лингвистическому обеспечению
системы»
определяют
языки
программирования,
которые
будут
применены в разработке. «Требования к программному обеспечению
системы» содержат список необходимого программного обеспечения для
работы системы. «Техническое обеспечение» определяет минимальные
системные требования, предъявляемые оборудованию. Требования к
метрологическому обеспечению описывают
метрологических норм,
правил и методик выполнения измерений. Не предъявляются к системе
Juice-CRM.
Организационное
обеспечение
включает
требования
к
53
структуре и функциям подразделений, участвующих в функционировании
системы или обеспечивающих эксплуатацию, порядку взаимодействия
объекта автоматизации с системой. Определяются способы защиты от
ошибочных действий пользователей.
Требования к методическому
обеспечению содержит перечень стандартов, применяемых к функциям
системы. Основные функции Juice-CRM специфичны и не имеют
применимых стандартов к ним.
5) Состав и содержание работ по созданию системы;
Представлен
списком
этапов
жизненного
цикла
разработки
программного средства, указывающий время, затраченное на каждый
этап. Детальный перечень работ указывается в документе «Задание на
разработку».
6) Порядок контроля и приемки системы:
виды, состав, объем и способы испытаний программного
средства и его подсистем;
требования
к
приемке
работ,
порядок
согласования
и
утверждения приемочной документации.
7) Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие.
Утверждает основные мероприятия, требуемые к выполнению при
подготовке объекта автоматизации к внедрению программного средства в
рабочие процессы организации.
8) Требования к документированию:
продукта
согласованный исполнителем и заказчиком программного
пакет
документов,
подлежащих
разработке
согласно
требованиям ГОСТ 34.201-89 «Виды, комплектность и обозначения
документов при создании автоматизированных систем»;
перечень электронных документов;
54
требования по документированию комплектующих элементов
применения в соответствии с требованиями ЕСКД 43 и ЕСПД44.
9) Источники разработки:
В
заключительном
информационные
обоснование
разделе
материалы,
и
указываются
например
информационные
документация
и
технико-экономическое
материалы
на
аналогичные
разрабатываемой системы, на основании которых разрабатывалось
«Техническое задание» и которые могут быть полезны разработчику при
проектировании и исполнении программного средства.
Описанная структура основана на государственном стандарте
34.602-89
«Информационная
технология.
автоматизированные
системы.
автоматизированной
системы» 45
Комплекс
Техническое
и
задание
полностью
ему
стандартов
на
на
создание
соответствует,
вследствие чего может быть применена организацией ООО «Джус
Девелопмент» на практике, на этой основе будет разработана форма
документа «Техническое Задание», которая представлена в приложении 1
к данной работе.
§ 2. Проектирование унифицированной формы паспорта на
автоматизированную систему
В данном параграфе содержится обоснование структуры документа,
относящегося
к
категории
эксплуатационной
документации.
Он
Единая система конструкторской документации. (ЕСКД) . – URL: http://eskd.ru (дата
обращения 26.05.2018).
44
Единая
система
программной
документации
(ЕСПД)
.
–
URL:
http://www.rugost.com/index.php?option=com_content&view=category&id=19&Itemid=50
(дата обращения 26.05.2018).
45
ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание автоматизированной
системы». – URL:
http://www.rugost.com/index.php?option=com_content&view=article
&id=96&catid=22&Itemid=53 (дата обращения 26.05.2018).
43
55
предназначен для конечного пользователя – заказчика разработки
информационной системы.
В ходе выполнения магистерской диссертации была спроектирована
унифицированная форма документа «Паспорт на программное средство».
Основой
для
разработки
унифицированной
формы
является
государственному стандарту России ИСО 9127-94 «Системы обработки
информации. Документация пользователя и информация на упаковке для
потребительских программных пакетов» 46.
Титульный лист паспорта оформляется аналогично титульному
листу технического задания, за исключением грифа согласования, так как
этот документ составляется без заказчика.
Документ содержит в себе восемь разделов, которые поделены на
подразделы:
1) Общие сведения о программном средстве:
название программного продукта;
обозначение, присвоенное разработчиком;
организация-поставщик данного программного обеспечения.
В данном разделе, для идентификации программного продукта,
указывается полное название системы, её технологическое обозначение и
полное
наименование
организации,
разработавшей
программное
средство.
2) Основные характеристики автоматизированной системы:
функции системы;
описание принципов работы продукта;
общий регламент и режимы функционирования программного
средства;
ГОСТ Р ИСО 9127-94 «Системы обработки информации. Документация пользователя и
информация на упаковке для потребительских программных пакетов». – URL:
http://docs.cntd.ru/document/gost-r-iso-9127-94 (дата обращения 26.05.2018).
46
56
сведения
о
совместимости
с
другим
программным
обеспечением.
Раздел включает список функций, реализованных в системе и их
характеристику. В нём описываются принципы функционирования
системы: языки программирования, на которых написан продукт и их
особенности. Регламент режимов работ характеризует особенности
работы
системы.
круглосуточно.
Программный
Уточняется
продукт
Juice-CRM
месторасположение
и
работает
принадлежность
серверного оборудования. В сведениях о совместимости указывают
минимальные
системные
требования
для
эксплуатации
автоматизированной системы.
3) Комплектность:
состав коммерческого пакета;
список
эксплуатационных
документов,
сопровождающих
автоматизированную систему.
Состав коммерческого пакета состоит из компонентов, предоставляемых
разработчиком заказчику при передаче автоматизированной системы. Как
правило,
пакет
состоит
из
элементов
программного
продукта,
размещённых на электронном носителе в нескольких экземплярах, а
также
сопровождающие
документы
в
бумажной
форме.
Список
сопровождающих документов также указывается в данном разделе.
4) Акт о приемке:
содержание и дата подписания акта о приемке программного
средства в эксплуатацию;
имена и должности лиц, подписавших акты.
Раздел
указывает
дату
подписания
акта
о
приёмке
автоматизированной системы и состав комиссии, подписавшей его.
5) Гарантийные обязательства разработчика:
период гарантии;
57
работы в рамках гарантии;
сроки выполнения работ по гарантии.
Определяет сроки и ограничения гарантийного обслуживания на
поставляемый программный продукт. Указывается перечень работ,
осуществляемых по гарантии, срок их выполнения и период гарантийного
обслуживания.
6) Сведения о рекламациях, в которых регистрируются все
предъявленные рекламации, их краткое содержание и меры, принятые по
рекламациям.
В разделе регистрируют все предъявленные претензии заказчика, их
краткое содержание и принятые разработчиком меры.
Данная структура соответствует ГОСТу Р ИСО 9127-94 «Системы
обработки информации. Документация пользователя и информация на
упаковке для потребительских программных пакетов» и РД 50-34.698-90
«Методические
указания.
Информационная
технология.
Автоматизированные системы. Требования к содержанию документов» и
может быть использована организацией ООО «Джус Девелопмент» на
практике.
Это
позволяет
рекомендовать
унифицированную
форму
документа «Паспорт на автоматизированную систему», представленную в
приложении 2 к данной работе, в качестве одного из элементов
совершенствования
документирования
разработки
и
внедрения
автоматизированных систем.
Спроектированные унифицированные формы будут включены в
состав системы документирования программных средств и будут
применяться компанией при создании документов на разработку и
внедрение конкретных информационных систем.
58
ЗАКЛЮЧЕНИЕ
В настоящее время, в связи с активной автоматизацией бизнеспроцессов и необходимостью тщательного документирования процесса
информатизации. Разработка и внедрение автоматизированной системы в
функциональные подразделения компании, позволяет переложить ручной
труд на машинный, тем самым сократив время и штат сотрудников для
решения определённых задач. Создание программного продукта является
ответственным процессом,
потому документирование разработки и
внедрения автоматизированной системы имеет большую роль в проекте.
Анализ потребности документационного обеспечения процесса разработки
автоматизированной системы позволил определить основные проблемы, с
которыми может столкнуться организация-разработчик. Для решения
проблем разработки и документирования процесса создания и внедрения
программных продуктов необходимо использование нормативной базы
документирования разработки и внедрения автоматизированных систем,
включающей в себе характеристику российских и международных
стандартов документирования автоматизированных систем.
Общество с ограниченной ответственностью «Джус Девелопмент»,
являющееся
разработчиком
программного
обеспечения,
выступило
объектом анализа для выявления проблем, присутствующих в практике
процесса документирования разработки и внедрения автоматизированных
систем. Для этого была дана характеристика самой организации и её
основного
программного
продукта
–
являющейся
Juice-CRM,
многофункциональной автоматизированной системой, версии которой
разрабатываются индивидуально для каждого заказчика.
В
результате
проведённого
анализа
текущей
системы
документирования разработки и внедрения автоматизированных систем
ООО
«Джус
Девелопмент»
были
выявлено
несоответствие
59
технологических документов стандартам, включенных в нормативную базу
документирования программных средств, а также отсутствие необходимой
эксплуатационной документацией.
На основании результатов анализа была определена потребность
разработки унифицированной формы технического задания и разработки
новой формы эксплуатационной документации — унифицированной
формы паспорта на автоматизированную систему, поставляемого в
коммерческом пакете программного продукта заказчику после завершения
работ по разработке программного обеспечения.
Унифицированная форма ТЗ-1 разработана на основе требований
ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на
автоматизированные
системы.
Техническое
задание
на
создание
автоматизированной системы», в котором описан перечень разделов
документа и дана их характеристика. Унифицированная форма П-1
основана на структуре, описанной в стандартах ГОСТ Р ИСО 9127-94
«Системы
обработки
информации.
Документация
пользователя
и
информация на упаковке для потребительских программных пакетов» и РД
50-34.698-90 «Методические указания. Информационная технология.
Автоматизированные системы. Требования к содержанию документов».
Спроектированные унифицированные формы, после утверждения
приказом генерального директора ООО «Джус Девелопмент» будут
являться обязательными для использования в данной организации, что
позволит
оптимизировать
работы
по
документированию
в
рассматриваемой сфере. Формы будут включены в состав системы
документирования программных средств и будут применяться компанией
при создании документов на разработку и внедрение конкретных
информационных
Девелопмент».
систем
компанией-разработчиком
ООО
«Джус
60
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
I. Источники
Неопубликованные источники
1.
Устав
Девелопмент»
Общества
(утвержден
с
ограниченной
протоколом
ответственностью
общего
собрания
«Джус
участников
Общества от 14.01.2017 № 01-01). – Белгород, 2017. – 32 с.
Опубликованные источники
2. ГОСТ 34.003-90. Информационная технология. Комплекс стандартов
на автоматизированные системы. Автоматизированные системы. Термины и
определения. – М.: ИПК Издательство стандартов, 2002. – 20 с.
3. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов
на
автоматизированные
системы.
Техническое
задание
на
создание
автоматизированной системы. – М.: ИПК Издательство стандартов, 2002. –
15 с.
4.
ГОСТ
34.2001-89.
Информационная
технология.
Комплекс
стандартов на автоматизированные системы. Виды, комплектсность и
обозначение документов при создании автоматизированных систем. – М.:
ИПК Издательство стандартов, 2008. – 11 с.
5. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов
на автоматизированные системы. Автоматизированные системы стадии
создания. - М.: ИПК Издательство стандартов, 1990. – 24 с.
6. ГОСТ Р 6.30-2003. Унифицированные системы документации.
Унифицированная
система
организационно-распорядительной
61
документации. Требования к оформлению документов. – М.: ИПК Изд-во
стандартов, 2003. – 20 с.
7. ГОСТ 2.105.95 ЕСКД. Общие требования к текстовым документам. –
М.: ИПК Издательство стандартов, 2000. – 30 с.
8. ГОСТ 2.301-68 ЕСКД Форматы. – М.: ИПК Издательство стандартов,
1990. – 4 с.
II. Литература
9. Назаров, С.В. Архитектуры и проектирование программных систем:
монография / С.В. Назаров. – М.: ИНФРА-М, 2013. – 88 с.
10. Липаев, В.В. Программная инженерия / В.В. Липаев.– М.: «ТЕИС»,
2006. – 609 с.
11. Липаев, В.В. Экономика производства программных продуктов /
В.В. Липаев. – М.: СИНТЕГ, 2011. – 358 с.
12. Савельева, Н. Системы управления контентом / Н. Савельева //
Открытые системы. – 2004. – № 4. – С. 25.
13. Колисниченко, Д.Н. Движок для вашего сайта. CMS Joomla!, Slaed,
PHP-Nuke / Д.Н. Колисниченко. – СПб.: «Петербург: БХВ», 2008. – 368 с.
14.
Казаков, Б.В. Основы работы в MySQL: учеб. пособие / Б.В.
Казаков. – Пенза: Изд-во ПГУ, 2012. – 92 с.
15. Кучик Е. Любая автоматизированная система создается человеком //
Кадровик. – 2008.- № 11(15). – С. 57.
16.
Баласанян,
В.Э.
Применение
автоматизированных
систем
документационного обеспечения управления для повышения эффективного
управления / В.Э. Баласанян // Делопроизводство. – 2002.- № 2. – С. 27-30.
17. Гагарина, Л.Г. Разработка и эксплуатация автоматизированных
информационных систем / Л.Г. Гагарина, Д.В. Киселев, Е.Л. Федотова. – М.:
Форум, 2009. – 384 с.
62
18. Гайдамакин, Н.А. Автоматизированные информационные системы,
базы и банки данных. – М.: Гелиос АРВ, 2002 – 312 с.
19.
Гвоздева,
В.А.
Основы
построения
автоматизированных
информационных систем: учебник / В.А. Гвоздева, И.Ю Лаврентьева. – М.:
Инфра-М, 2007. – 320 с.
20. Кирсанова, М.В. Современное делопроизводство / М.В. Кирсанова.
– М.: ИНФРА-М, 2001. – 288 с.
21. Козлов, И. Программа не заменит человека. Проблема внедрения
Автоматизированных систем / И. Козлов // Новые системы финансового
учета. – 2007. - № 4.- С. 57-60.
22. Клоков И.В. Эффективное делопроизводство / О.В. Клоков, В.С.
Пташинский. – СПб.: Питер, 2008. – 224 с.
23.
Кузнецов,
автоматизации
С.Л.
Международные
требования
к
системам
делопроизводства / С.Л. Кузнецов //Делопроизводство. –
2006. - № 3. – С. 63-65.
III. Электронные ресурсы
24.
Внедрение
АИБС
«МАРК-SQL»
в
школьные
библиотеки
[Электронный ресурс]. – Электрон. данные – URL: http://www.gpntb.ru
/win/inter-events/crimea2008/disk/107.pdf
25.
Документация
разработки
автоматизированной
систем
[Электронный ресурс]. – Электрон. данные. – URL: http://www.philosoft.ru/
systems.zhtml#dev/
26. Как составить методические рекомендации [Электронный ресурс]. –
Электрон. данные. –URL: http://alekscdt.narod.ru/metodrek.html
27. ГОСТ 19.xxx. – URL: http://www.rugost.com/index.php?option=
com_content&tak=category§ionid=6&id=19&Itemid=50
63
28.
ГОСТ
34.601-90
Информационная
технология.
Комплекс
стандартов на автоматизированные системы. Стадии создания. [Электронный
ресурс].
–
Электрон.
данные.
–
URL:
http://www.rugost.com/
index.php?option=com_content&view=article&id=95&catid=22&Itemid=53
29. ГОСТ 34.603-92 Информационная технология. Виды испытаний
автоматизированных
систем.
–
URL:
http://www.rugost.com/index.php?
option=com_content&task=view& id=95&Itemid=53
30.
ГОСТ
34.602-89
Информационная
технология.
Комплекс
стандартов на автоматизированные системы. Техническое задание на
создание автоматизированной системы [Электронный ресурс]. – Электрон.
данные. – URL: http://www.rugost.com/index.php?option=com_content&view=
article&id=96&catid=22&Itemid=53
31. РД 50-34.698-90 Методические указания. Информационная
технология. Автоматизированные системы. Требования к содержанию
документов. [Электронный ресурс]. – Электрон. данные. – URL:
http://www.rugost.com/index.php?option=com_content&view=article&id=98:5034698-90&catid=22&Itemid=53
32. Международная организация по стандартизации, ИСО (International
Organization for Standardization, ISO). [Электронный ресурс]. – Электрон.
данные. – URL: https://ru.wikipedia.org/wiki/Международная_организация_
по_стандартизации #cite_note-general_vocabulary-1
33.
ГОСТ Р ИСО/МЭК 15910-2002 Информационная технология.
Процесс создания документации пользователя программного средства
[Электронный ресурс]. – Электрон. данные. – URL: http://www.rugost.com/
index.php?option=com_content&view=article&id=102:159102002&catid=22&Ite
mid=53
34.
ГОСТ
Р
ИСО
9127-94
Системы
обработки
информации.
Документация пользователя и информация на упаковке для потребительских
64
программных пакетов. [Электронный ресурс]. – Электрон. данные. – URL:
http://docs.cntd.ru/document/gost-r-iso-9127-94
35. IEEE 1063-2001 – IEEE Standard for Software User Documentation
[Электронный ресурс]. – Электрон. данные. – URL:
http://standards.
ieee.org/findstds/standard/1063-2001.html
Система управления взаимоотношениями с клиентами (CRM,
36.
CRM-система, сокращение от англ. Customer Relationship Management)
[Электронный ресурс]. – Электрон. данные. – URL: https://ru.wikipedia.org/
wiki/Система_управления_взаимоотношениями_с_клиентами
37. PHP (Hypertext Preprocessor – «PHP: препроцессор гипертекста»
[Электронный ресурс]. – Электрон. данные. – URL:
https://ru.wikipedia.org/wiki/PHP
38. API (программный интерфейс приложения, интерфейс прикладного
программирования) application programming interface, API) [Электронный
ресурс]. – Электрон. данные. – URL: https://ru.wikipedia.org/wiki/API
39. SQL structured query language – «язык структурированных запросов»
[Электронный ресурс]. – Электрон. данные. – URL:
https://ru.wikipedia.org/wiki/SQL
40. XSS Cross-Site Scripting – «межсайтовый скриптинг» [Электронный
ресурс]. – Электрон. данные. – URL:
https://ru.wikipedia.org/wiki/Межсайтовый_скриптинг
41.
ГОСТ
Федерации.
Р
Система
издательскому
делу.
7.0.97-2016.
стандартов
Национальный
по
стандарт
информации,
Российской
библиотечному
Организационно-распорядительная
и
документация.
Требования к оформлению документов [Электронный ресурс]. – Электрон.
данные. – URL: http://www.consultant.ru/document/cons_doc_LAW_216461/
(дата обращения 26.05.2018).
Отзывы:
Авторизуйтесь, чтобы оставить отзыв