Commit 3069ebee authored by root's avatar root

c-m

parent 29a0c786
/* override table width restrictions */
@media screen and (min-width: 767px) {
.wy-table-responsive table td {
/* !important prevents the common CSS stylesheets from overriding
this as on RTD they are loaded after this stylesheet */
white-space: normal !important;
}
.wy-table-responsive {
overflow: visible !important;
}
}
\ No newline at end of file
# -*- coding: utf-8 -*-
#
# Read the Docs Template documentation build configuration file, created by
# sphinx-quickstart on Tue Aug 26 14:19:49 2014.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#sys.path.insert(0, os.path.abspath('.'))
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as Strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = []
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'Спецификация требований Synergy Showcase'
copyright = u'2018, ARTA Software'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = '0.1'
# The full version, including alpha/beta/rc tags.
release = '0.1-alpha'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['_build']
# The reST default role (used for this markup: `text`) to use for all
# documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
#keep_warnings = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
html_context = {
'css_files': [
'_static/theme_overrides.css', # override wide tables in RTD theme
],
}
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
#html_extra_path = []
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
#html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'ReadtheDocsTemplatedoc'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
('index', 'ReadtheDocsTemplate.tex', u'Read the Docs Template Documentation',
u'Read the Docs', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
('index', 'readthedocstemplate', u'Спецификация требований Synergy Showcase',
[u'Read the Docs'], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'ReadtheDocsTemplate', u'Read the Docs Template Documentation',
u'Read the Docs', 'ReadtheDocsTemplate', 'One line description of project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False
\ No newline at end of file
Условные обозначения
====================
В настоящем документе используются следующие определения, сокращения и аббревиатуры:
* **ОС** - операционная система;
* **ИС** - информационная система;
* **Система** - ИС «Showcase»;
* **НУЦ РК** - Национальный удостоверяющий центр Республики Казахстан;
* **ЭЦП** - Электронная цифровая подпись;
* **СЭД** - Система электронного документооборота;
* **СУБД** - система управления базами данных;
* **Справочник** - перечень заранее определенных значений параметров объектов системы;
* **Форма** - тип файла в Платформе, предназначенный для сбора и отображения структурированных данных;
* **Реестр** - способ представления данных по Форме в табличном виде;
* **Запись** - документ на основе Формы в Реестре.
* **Работа** - объект системы, представляющий собой сформулированное автором требование выполнить действие за конечное время и возложенное на конкретного исполнителя (ответственного).
* **Приоритет** - атрибут работы, определяющий важность её исполнения. Названия и параметры имеют возможность настройки.
* **Нагрузка** - атрибут работы, определяющий время, выделенное на выполнение данной работы. Нагрузка может быть выражена в количестве часов в день, в количестве часов всего, в количестве рабочих дней, в проценте от рабочего времени. Данный параметр работы участвует в формулах расчета общей нагрузки пользователя и его эффективности.
* **Прогресс** - атрибут работы, характеризующий процент её выполнения (от 0% до 100%).
* **Статус** - атрибут работы, определяющий статус работы в системе:
* зависящий от прогресса ее исполнения и типа:
* «в работе»;
* «ожидание» (<100%);
* «завершена»;
* «согласовано»/ «не согласовано», «ознакомлен», «утверждено»/ «не утверждено» (=100%);
* не зависящий от прогресса:
* «удалена».
* **Маршрут** - многократно используемый набор Работ и правил переходов, связанных последовательно и/или параллельно, направленных на достижение заранее определённого результата.
* **Фильтры работ** - способ группировки работ в зависимости от их свойств и по отношению пользователя к работе (на исполнении, на контроле).
* **Согласование** - работа, требующая в качестве своего завершения выбора одного из пунктов: согласовано или не согласовано, позволяющая также при выборе ввести комментарий.
* **Утверждение** - работа, требующая в качестве своего завершения выбора одного из пунктов: утверждено или не утверждено, позволяющая также при выборе ввести комментарий.
* **Ознакомление** - работа, требующая в качестве своего завершения выбора пункта: ознакомился.
* **Документ** - именованный контейнер в Хранилище, содержащий реквизиты и файлы, а также их версии. Реквизиты содержат: Карточку документа (в зависимости от типа), Ход исполнения, Изменения в документе, Листы подписей.
* **Дочерний документ** - документ, созданный на основании данного. Связь «основание - дочерний» отображается в карточке документа.
* **Основание документ** - документ, на основании которого был создан данный. Связь «основание - дочерний» отображается в карточке документа.
_________________________________________________________________________
* **Обращение (инцидент или заявка на обслуживание)** - Документ (в терминах системы), позволяющий хранить структурированные данные об инциденте ( - незапланированном прерывании или снижении качества ИТ-услуги, сбои конфигурационной единицы) или заявке на обслуживание по утвержденной форме.
* **Проблема (запись о проблеме)**- Документ (в терминах системы), позволяющий хранить структурированные данные о проблеме (-причине одного или нескольких инцидентов) по утвержденной форме.
* **Конфигурационная единица** - Документ (в терминах системы), позволяющий хранить структурированные данные по утвержденной форме о любом компоненте или другом сервисном активе, которым необходимо управлять для того, чтобы предоставлять ИТ-услугу.
* **Соглашение об уровне услуг (SLA)** - Документ (в терминах системы), позволяющий хранить структурированные данные о соглашении (целевые показатели уровня услуги, зоны ответственности сторон) по утвержденной форме.
* **Лицензия** - Документ (в терминах системы), позволяющий хранить структурированные данные о лицензии по утвержденной форме.
* **Наряд** - Документ (в терминах системы), позволяющий хранить структурированные данные о наряде (формальном запросе на выполнение определенной деятельности) по утвержденной форме.
* **Оценка сервиса** - Документ (в терминах системы), позволяющий хранить структурированные данные об оценке качества предоставляемого сервиса по устранению инцидента.
* **Запись базы знаний** - Документ (в терминах системы), позволяющий хранить структурированные данные (- точек зрения,идей, опыта, информации) по утвержденной форме.
* **Услуга(сервис)** - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (описании желаемых результатов, ценовой политике, пакетах обслуживания и пр.) по утвержденной форме.
* **Спецификация услуги** - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (сервисные условия, связанные внутренние и внешние IT сервисы, процедурные оценки, финансы) по утвержденной форме.
* **Карточка контакта** - Документ (в терминах системы), позволяющий хранить структурированные данные о контакте (сотруднике организации) по утвержденной форме.
* **Карточка организации** - Документ (в терминах системы), позволяющий хранить структурированные данные об организации по утвержденной форме.
* **Запрос на изменение (RFC)** - (RFC - Request for changes). Документ (в терминах системы), позволяющий хранить структурированные данные о запросе (-формальном предложении на выполнение изменений) по утвержденной форме.
* **Запись об изменении (CR)** - (CR - Change record). Документ (в терминах системы), позволяющий хранить структурированные данные об изменении по утвержденной форме. Прим. Запись об изменении (CR) может являться дочерним документом для запроса на изменение (RFC)
Цели создания
=============
Целью создания Synergy ITSM является реализация автоматизации следующих ключевых процессов:
* Управление обращениями (инцидентами и заявками на обслуживание)
* Управление проблемами
* Управление уровнем услуг (SLA)
* Управление знаниями
* Управление конфигурациями
* Управление изменениями
.. Read the Docs Template documentation master file, created by
sphinx-quickstart on Tue Aug 26 14:19:49 2014.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Содержание
==========
.. toctree::
:maxdepth: 2
:glob:
:numbered:
goals
glossary
requirements
Требования к разработке ИС «Showcase»
=====================================
Общие требования к Системе
------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.1.1, "Система должна поддерживать работу на следующих серверных операционных системах: Linux, BSD, Solaris (рекомендуется использовать ОС Debian GNU/Linux 6.0 (amd64)."
3.1.2, "Система должна поддерживать работу на реляционных СУБД и на noSQL СУБД."
3.1.3, "Система не требует обязательного приобретения дополнительных компонентов (лицензии на ОС, на СУБД и т.п.)."
3.1.4, "Система поддерживает шифрование подключений с помощью протокола SSL (HTTPS)."
3.1.5, "Система должна поддерживать работу с распределённым хранилищем данных."
3.1.6, "Система должна обеспечивать возможность распределенной работы и удаленного доступа к ресурсам и объектам."
3.1.7, "Система должна поддерживать работу в архитектуре Internet/Intrаnet."
3.1.8, "Система должна предоставлять Web-интерфейс, который не требует установки клиентской части. Система должна поддерживать интернет-браузеры Google Chrome, Mozilla Firefox актуальных версий."
3.1.9, "Система должна предоставлять возможность реализовывать пользовательские интерфейсы, используя HTML и/или JavaScript."
3.1.10, "Система должна предоставлять комплект средств разработки (Software Development Kit - SDK), включая: REST API; способы авторизации: сессионная, по логину и паролю, по ключам; события, возникающие в различных точках исполняемого кода при выполнении определённых условий; очереди сообщений; поддержку плагинов; JavaScript интерпретаторы."
3.1.11, "Система должна предоставлять инструментарий для локализации языка интерфейса. Система должна обеспечить возможность добавлять и настраивать неограниченное количество языков без программирования в процессе эксплуатации. А также позволять изменять переводы в режиме реального времени, без остановки системы и без применения сторонних инструментов."
3.1.12, "Система должна предоставлять возможность администрирования организационной структуры, функциональных ролей и учетных записей пользователей."
3.1.13, "Система должна предоставлять возможность регулирования доступа к объектам платформы в соответствии с правами доступа пользователя."
3.1.14, "Система должна предоставлять возможность создания, редактирования форм в визуальном редакторе форм."
3.1.15, "Система должна предоставлять инструмент управления бизнес-процессами, поддерживающий нотацию BPMN."
3.1.16, "Система должна предоставлять дизайнер бизнес-процессов. Создание и редактирование бизнес-процессов должно выполняться в рабочем пространстве дизайнера бизнес-процессов."
3.1.17, "Система должна поддерживать версионность документов."
Требования к процессу “Управление обращениями (инцидентами и заявками на обслуживание)”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.2.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление обращениями (инцидентами и заявками на обслуживание)”:
* Инициатор обращения (автор)
* Оператор
* Исполнитель
* Менеджер сервиса"
3.2.2, "Система должна позволять создавать/редактировать/удалять обращение в соответствии с правами доступа."
3.2.3, "Система должна позволять в описании обращения указывать:подробную информацию об авторе (с автоматической подстановкой данных, при их наличии) детальное описания инцидента или заявки на обслуживание, классификацию (по услугам и SLA, типу запроса, приоритету инициатора), ранжирование (по важности/срочности), связи с услугами, проблемами, конфигурационными единицами и другими обращениями."
3.2.4, "Система должна позволять пользователю с ролью Оператор указывать Исполнителя по обращению и сроков его исполнения."
3.2.5, "Система должна позволять осуществлять маршрут исполнения обращения согласно текущему его статусу."
3.2.6, "Система должна позволять создавать один или несколько нарядов на основе данного инцидента. Наряд, в свою очередь, может включать в себя одну или несколько работ."
3.2.7, "Система должна позволять осуществлять координацию реализации работ по наряду. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.2.8, "В Системе должен быть предусмотрен рабочий календарь обращения, автоматически определяемый по услуге и SLA, по рабочему календарю для дальнейшего отсчет временных метрик;"
3.2.9, "В системе должен быть предусмотрен возврат обращений “на доработку” с автоматическим приостановлением расчета временных метрик."
3.2.10, "Система должна поддерживать функцию вертикальной эскалации (передачу инцидента на более высокий уровень по оргструктуре), при нарушении SLA. В системе должна быть предусмотрена возможность настройки механизма эскалации по счетчикам (количество переназначений исполнителя, количество переклассификаций обращения и т.п.)"
3.2.11, "Система должна предусматривать назначения обращения определенному ответственному или группе, а также назначению ответственного в рамках выбранной группы. Система должна предусматривать возможность переназначения с группы на группу, на ответственного и т.д."
3.2.12, "По завершению работ по инциденту, система должна позволять вносить описание решения в запись об инциденте, а также осуществлять оценку сервиса пользователю с ролью Менеджер сервиса."
3.2.13, "Система должна предусматривать возможность завершения обращения без необходимости вносить оценку, принятия инициатором."
3.2.14, "Система должна предоставлять возможность перехода по всем связанным объектам (обращение - проблема- услуга - конфигурационная единица), а также возвращению необходимых значений в связанные объекты, при изменении статуса основного."
3.2.15, "В Системе должна быть возможность выполнять информирование инициатора обращения (e-mail-уведомления) на всех этапах жизненного цикла обращения"
3.2.16, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех обращений, а также осуществлять поиск и фильтрацию по ключевым полям формы."
3.2.17, "Система должна поддерживать интеграцию с электронной почтой на предмет получения записей об инцидентах."
3.2.18, "Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей об инцидентах."
3.2.19, "В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал."
Требования к процессу “Управление проблемами”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.3.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление проблемами”:
* Инициатор записи о проблеме(автор)
* Оператор
* Исполнитель
* Менеджер сервиса"
3.3.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись о проблеме."
3.3.3, "Система должна позволять в описании проблемы указывать подробную информацию об авторе, отличать проблему от известной ошибки, детальное описание самой проблемы, а также указывать связи с сервисами, инцидентами и другими проблемами. "
3.3.4, "Система должна позволять пользователю с ролью Оператор указывать Исполнителя по инциденту и сроков его исполнения."
3.3.5, "Система должна позволять осуществлять маршрут исполнения проблемы согласно текущему её статусу."
3.3.6, "Система должна позволять осуществлять координацию реализации работ маршрута проблемы. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.3.7, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех проблем, а также осуществлять поиск и фильтрацию по ключевым полям формы."
3.3.8, "Система должна поддерживать интеграцию с электронной почтой на предмет получения записей о проблемах."
3.3.9, "Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей о проблемах."
Требования к процессу “Управление уровнем услуг (SLA)”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.4.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление уровнем услуг(SLA)”: Менеджер услуг (SLA)."
3.4.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку контакта по установленной форме."
3.4.3, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку организации по установленной форме."
3.4.4, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа соглашение об уровне обслуживания с заполнением основной информации, описании ожидаемых результатов, взаимодействия и ответственности сторон, условия предоставления услуг."
3.4.5, "Система должна предоставлять возможность заполнения истории изменения Соглашений об уровне обслуживания (SLA)."
3.4.6, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку Усулги по установленной форме с заполнением основной и подробной и информации, а также привязки к другой услуге."
3.4.7, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех:
* Контактов
* Организаций
* Услуг
* Соглашений об уровне обслуживания (SLA)
* А также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Требования к процессу “Управление знаниями”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.5.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление знаниями”: Инициатор записи Базы знаний - любой пользователь системы, имеющий право доступа на создание записи в соответствующем реестре."
3.5.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись базы знаний с заполнением основной и подробной информации по установленной форме."
3.5.3, "Система должна позволять связывать запись базы знаний с зарегистрированными инцидентами и проблемами в соответствующих реестрах."
3.5.4, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей Базы знаний, а также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Требования к процессу “Управление конфигурациями”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.6.1, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Конфигурационную Единицу по установленной форме"
3.6.2, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех конфигурационных единиц. А также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Требования к процессу “Управление изменениями”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.7.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление изменениями”:
* Инициатор RFC - Любой сотрудник компании, являющийся автором и отправителем Заявки на изменение RFC
* Совет по изменениям (CAB) - группа пользователей, согласующими RFC или CR на разных этапах процесса.
* Эксперт - Сотрудник компании (н-р, сотрудник IT отдела) являющийся экспертом по данному вопросу из RFC, обладающие компетенциями чтобы провести оценку рисков, ресурсов, составить план работ и план отката.
* Менеджер SC- Сотрудник компании (н-р, руководитель IT отдела), распределяющий нагрузку среди исполнителей работ по изменениям, назначающий сроки исполнения этих работ. (управляет Графиком изменений)
* Исполнитель - Сотрудник, отвечающий за исполнение конкретной работы по плану реализации или плану отката CR"
3.7.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запрос на изменение (RFC) с заполнением следующей основной информации о запросе. А также дополнительной информации, позволяющей классифицировать данный запрос по важности/срочности, связывать запрос на изменение (RFC) с касающимися его услугами."
3.7.3, "Система должна позволять осуществлять процесс согласования запроса на изменения (RFC) с советом по изменения (CAB), а также с другимизаинтересованными лицами."
3.7.4, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа на основании запроса на изменение (RFC) запись об изменении CR: определять план реализации и план отката, а также необходимость включения в Релиз."
3.7.5, "Система должна позволять осуществлять маршрут согласования CR c советом по изменениям (CAB), а также другими заинтересованными лицами."
3.7.6, "Система должна позволять пользователю с ролью менеджер SC определять сроки исполнения работ по плану реализации и плану отката CR."
3.7.7, "Система должна позволять осуществлять координацию реализации работ по плану реализации и плану отката CR. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.7.8, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех запросов на изменения (RFC) и записей об изменении (CR), а также осуществлять поиск и фильтрацию по ключевым полям данных форм."
/* override table width restrictions */
@media screen and (min-width: 767px) {
.wy-table-responsive table td {
/* !important prevents the common CSS stylesheets from overriding
this as on RTD they are loaded after this stylesheet */
white-space: normal !important;
}
.wy-table-responsive {
overflow: visible !important;
}
}
\ No newline at end of file
# -*- coding: utf-8 -*-
#
# Read the Docs Template documentation build configuration file, created by
# sphinx-quickstart on Tue Aug 26 14:19:49 2014.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#sys.path.insert(0, os.path.abspath('.'))
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as Strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = []
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'Спецификация требований Synergy Showcase'
copyright = u'2018, ARTA Software'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = '0.1'
# The full version, including alpha/beta/rc tags.
release = '0.1-alpha'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['_build']
# The reST default role (used for this markup: `text`) to use for all
# documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
#keep_warnings = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
html_context = {
'css_files': [
'_static/theme_overrides.css', # override wide tables in RTD theme
],
}
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
#html_extra_path = []
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
#html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'ReadtheDocsTemplatedoc'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
('index', 'ReadtheDocsTemplate.tex', u'Read the Docs Template Documentation',
u'Read the Docs', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
('index', 'readthedocstemplate', u'Спецификация требований Synergy Showcase',
[u'Read the Docs'], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'ReadtheDocsTemplate', u'Read the Docs Template Documentation',
u'Read the Docs', 'ReadtheDocsTemplate', 'One line description of project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False
\ No newline at end of file
Условные обозначения
====================
В настоящем документе используются следующие определения, сокращения и аббревиатуры:
* **ОС** - операционная система;
* **ИС** - информационная система;
* **Система** - ИС «Showcase»;
* **НУЦ РК** - Национальный удостоверяющий центр Республики Казахстан;
* **ЭЦП** - Электронная цифровая подпись;
* **СЭД** - Система электронного документооборота;
* **СУБД** - система управления базами данных;
* **Справочник** - перечень заранее определенных значений параметров объектов системы;
* **Форма** - тип файла в Платформе, предназначенный для сбора и отображения структурированных данных;
* **Реестр** - способ представления данных по Форме в табличном виде;
* **Запись** - документ на основе Формы в Реестре.
* **Работа** - объект системы, представляющий собой сформулированное автором требование выполнить действие за конечное время и возложенное на конкретного исполнителя (ответственного).
* **Приоритет** - атрибут работы, определяющий важность её исполнения. Названия и параметры имеют возможность настройки.
* **Нагрузка** - атрибут работы, определяющий время, выделенное на выполнение данной работы. Нагрузка может быть выражена в количестве часов в день, в количестве часов всего, в количестве рабочих дней, в проценте от рабочего времени. Данный параметр работы участвует в формулах расчета общей нагрузки пользователя и его эффективности.
* **Прогресс** - атрибут работы, характеризующий процент её выполнения (от 0% до 100%).
* **Статус** - атрибут работы, определяющий статус работы в системе:
* зависящий от прогресса ее исполнения и типа:
* «в работе»;
* «ожидание» (<100%);
* «завершена»;
* «согласовано»/ «не согласовано», «ознакомлен», «утверждено»/ «не утверждено» (=100%);
* не зависящий от прогресса:
* «удалена».
* **Маршрут** - многократно используемый набор Работ и правил переходов, связанных последовательно и/или параллельно, направленных на достижение заранее определённого результата.
* **Фильтры работ** - способ группировки работ в зависимости от их свойств и по отношению пользователя к работе (на исполнении, на контроле).
* **Согласование** - работа, требующая в качестве своего завершения выбора одного из пунктов: согласовано или не согласовано, позволяющая также при выборе ввести комментарий.
* **Утверждение** - работа, требующая в качестве своего завершения выбора одного из пунктов: утверждено или не утверждено, позволяющая также при выборе ввести комментарий.
* **Ознакомление** - работа, требующая в качестве своего завершения выбора пункта: ознакомился.
* **Документ** - именованный контейнер в Хранилище, содержащий реквизиты и файлы, а также их версии. Реквизиты содержат: Карточку документа (в зависимости от типа), Ход исполнения, Изменения в документе, Листы подписей.
* **Дочерний документ** - документ, созданный на основании данного. Связь «основание - дочерний» отображается в карточке документа.
* **Основание документ** - документ, на основании которого был создан данный. Связь «основание - дочерний» отображается в карточке документа.
_________________________________________________________________________
* **Обращение (инцидент или заявка на обслуживание)** - Документ (в терминах системы), позволяющий хранить структурированные данные об инциденте ( - незапланированном прерывании или снижении качества ИТ-услуги, сбои конфигурационной единицы) или заявке на обслуживание по утвержденной форме.
* **Проблема (запись о проблеме)**- Документ (в терминах системы), позволяющий хранить структурированные данные о проблеме (-причине одного или нескольких инцидентов) по утвержденной форме.
* **Конфигурационная единица** - Документ (в терминах системы), позволяющий хранить структурированные данные по утвержденной форме о любом компоненте или другом сервисном активе, которым необходимо управлять для того, чтобы предоставлять ИТ-услугу.
* **Соглашение об уровне услуг (SLA)** - Документ (в терминах системы), позволяющий хранить структурированные данные о соглашении (целевые показатели уровня услуги, зоны ответственности сторон) по утвержденной форме.
* **Лицензия** - Документ (в терминах системы), позволяющий хранить структурированные данные о лицензии по утвержденной форме.
* **Наряд** - Документ (в терминах системы), позволяющий хранить структурированные данные о наряде (формальном запросе на выполнение определенной деятельности) по утвержденной форме.
* **Оценка сервиса** - Документ (в терминах системы), позволяющий хранить структурированные данные об оценке качества предоставляемого сервиса по устранению инцидента.
* **Запись базы знаний** - Документ (в терминах системы), позволяющий хранить структурированные данные (- точек зрения,идей, опыта, информации) по утвержденной форме.
* **Услуга(сервис)** - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (описании желаемых результатов, ценовой политике, пакетах обслуживания и пр.) по утвержденной форме.
* **Спецификация услуги** - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (сервисные условия, связанные внутренние и внешние IT сервисы, процедурные оценки, финансы) по утвержденной форме.
* **Карточка контакта** - Документ (в терминах системы), позволяющий хранить структурированные данные о контакте (сотруднике организации) по утвержденной форме.
* **Карточка организации** - Документ (в терминах системы), позволяющий хранить структурированные данные об организации по утвержденной форме.
* **Запрос на изменение (RFC)** - (RFC - Request for changes). Документ (в терминах системы), позволяющий хранить структурированные данные о запросе (-формальном предложении на выполнение изменений) по утвержденной форме.
* **Запись об изменении (CR)** - (CR - Change record). Документ (в терминах системы), позволяющий хранить структурированные данные об изменении по утвержденной форме. Прим. Запись об изменении (CR) может являться дочерним документом для запроса на изменение (RFC)
Цели создания
=============
Целью создания Synergy ITSM является реализация автоматизации следующих ключевых процессов:
* Управление обращениями (инцидентами и заявками на обслуживание)
* Управление проблемами
* Управление уровнем услуг (SLA)
* Управление знаниями
* Управление конфигурациями
* Управление изменениями
.. Read the Docs Template documentation master file, created by
sphinx-quickstart on Tue Aug 26 14:19:49 2014.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Содержание
==========
.. toctree::
:maxdepth: 2
:glob:
:numbered:
goals
glossary
requirements
Требования к разработке ИС «Showcase»
=====================================
Общие требования к Системе
------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.1.1, "Система должна поддерживать работу на следующих серверных операционных системах: Linux, BSD, Solaris (рекомендуется использовать ОС Debian GNU/Linux 6.0 (amd64)."
3.1.2, "Система должна поддерживать работу на реляционных СУБД и на noSQL СУБД."
3.1.3, "Система не требует обязательного приобретения дополнительных компонентов (лицензии на ОС, на СУБД и т.п.)."
3.1.4, "Система поддерживает шифрование подключений с помощью протокола SSL (HTTPS)."
3.1.5, "Система должна поддерживать работу с распределённым хранилищем данных."
3.1.6, "Система должна обеспечивать возможность распределенной работы и удаленного доступа к ресурсам и объектам."
3.1.7, "Система должна поддерживать работу в архитектуре Internet/Intrаnet."
3.1.8, "Система должна предоставлять Web-интерфейс, который не требует установки клиентской части. Система должна поддерживать интернет-браузеры Google Chrome, Mozilla Firefox актуальных версий."
3.1.9, "Система должна предоставлять возможность реализовывать пользовательские интерфейсы, используя HTML и/или JavaScript."
3.1.10, "Система должна предоставлять комплект средств разработки (Software Development Kit - SDK), включая: REST API; способы авторизации: сессионная, по логину и паролю, по ключам; события, возникающие в различных точках исполняемого кода при выполнении определённых условий; очереди сообщений; поддержку плагинов; JavaScript интерпретаторы."
3.1.11, "Система должна предоставлять инструментарий для локализации языка интерфейса. Система должна обеспечить возможность добавлять и настраивать неограниченное количество языков без программирования в процессе эксплуатации. А также позволять изменять переводы в режиме реального времени, без остановки системы и без применения сторонних инструментов."
3.1.12, "Система должна предоставлять возможность администрирования организационной структуры, функциональных ролей и учетных записей пользователей."
3.1.13, "Система должна предоставлять возможность регулирования доступа к объектам платформы в соответствии с правами доступа пользователя."
3.1.14, "Система должна предоставлять возможность создания, редактирования форм в визуальном редакторе форм."
3.1.15, "Система должна предоставлять инструмент управления бизнес-процессами, поддерживающий нотацию BPMN."
3.1.16, "Система должна предоставлять дизайнер бизнес-процессов. Создание и редактирование бизнес-процессов должно выполняться в рабочем пространстве дизайнера бизнес-процессов."
3.1.17, "Система должна поддерживать версионность документов."
Требования к процессу “Управление обращениями (инцидентами и заявками на обслуживание)”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.2.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление обращениями (инцидентами и заявками на обслуживание)”:
* Инициатор обращения (автор)
* Оператор
* Исполнитель
* Менеджер сервиса"
3.2.2, "Система должна позволять создавать/редактировать/удалять обращение в соответствии с правами доступа."
3.2.3, "Система должна позволять в описании обращения указывать:подробную информацию об авторе (с автоматической подстановкой данных, при их наличии) детальное описания инцидента или заявки на обслуживание, классификацию (по услугам и SLA, типу запроса, приоритету инициатора), ранжирование (по важности/срочности), связи с услугами, проблемами, конфигурационными единицами и другими обращениями."
3.2.4, "Система должна позволять пользователю с ролью Оператор указывать Исполнителя по обращению и сроков его исполнения."
3.2.5, "Система должна позволять осуществлять маршрут исполнения обращения согласно текущему его статусу."
3.2.6, "Система должна позволять создавать один или несколько нарядов на основе данного инцидента. Наряд, в свою очередь, может включать в себя одну или несколько работ."
3.2.7, "Система должна позволять осуществлять координацию реализации работ по наряду. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.2.8, "В Системе должен быть предусмотрен рабочий календарь обращения, автоматически определяемый по услуге и SLA, по рабочему календарю для дальнейшего отсчет временных метрик;"
3.2.9, "В системе должен быть предусмотрен возврат обращений “на доработку” с автоматическим приостановлением расчета временных метрик."
3.2.10, "Система должна поддерживать функцию вертикальной эскалации (передачу инцидента на более высокий уровень по оргструктуре), при нарушении SLA. В системе должна быть предусмотрена возможность настройки механизма эскалации по счетчикам (количество переназначений исполнителя, количество переклассификаций обращения и т.п.)"
3.2.11, "Система должна предусматривать назначения обращения определенному ответственному или группе, а также назначению ответственного в рамках выбранной группы. Система должна предусматривать возможность переназначения с группы на группу, на ответственного и т.д."
3.2.12, "По завершению работ по инциденту, система должна позволять вносить описание решения в запись об инциденте, а также осуществлять оценку сервиса пользователю с ролью Менеджер сервиса."
3.2.13, "Система должна предусматривать возможность завершения обращения без необходимости вносить оценку, принятия инициатором."
3.2.14, "Система должна предоставлять возможность перехода по всем связанным объектам (обращение - проблема- услуга - конфигурационная единица), а также возвращению необходимых значений в связанные объекты, при изменении статуса основного."
3.2.15, "В Системе должна быть возможность выполнять информирование инициатора обращения (e-mail-уведомления) на всех этапах жизненного цикла обращения"
3.2.16, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех обращений, а также осуществлять поиск и фильтрацию по ключевым полям формы."
3.2.17, "Система должна поддерживать интеграцию с электронной почтой на предмет получения записей об инцидентах."
3.2.18, "Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей об инцидентах."
3.2.19, "В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал."
Требования к процессу “Управление проблемами”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.3.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление проблемами”:
* Инициатор записи о проблеме(автор)
* Оператор
* Исполнитель
* Менеджер сервиса"
3.3.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись о проблеме."
3.3.3, "Система должна позволять в описании проблемы указывать подробную информацию об авторе, отличать проблему от известной ошибки, детальное описание самой проблемы, а также указывать связи с сервисами, инцидентами и другими проблемами. "
3.3.4, "Система должна позволять пользователю с ролью Оператор указывать Исполнителя по инциденту и сроков его исполнения."
3.3.5, "Система должна позволять осуществлять маршрут исполнения проблемы согласно текущему её статусу."
3.3.6, "Система должна позволять осуществлять координацию реализации работ маршрута проблемы. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.3.7, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех проблем, а также осуществлять поиск и фильтрацию по ключевым полям формы."
3.3.8, "Система должна поддерживать интеграцию с электронной почтой на предмет получения записей о проблемах."
3.3.9, "Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей о проблемах."
Требования к процессу “Управление уровнем услуг (SLA)”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.4.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление уровнем услуг(SLA)”: Менеджер услуг (SLA)."
3.4.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку контакта по установленной форме."
3.4.3, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку организации по установленной форме."
3.4.4, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа соглашение об уровне обслуживания с заполнением основной информации, описании ожидаемых результатов, взаимодействия и ответственности сторон, условия предоставления услуг."
3.4.5, "Система должна предоставлять возможность заполнения истории изменения Соглашений об уровне обслуживания (SLA)."
3.4.6, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку Усулги по установленной форме с заполнением основной и подробной и информации, а также привязки к другой услуге."
3.4.7, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех:
* Контактов
* Организаций
* Услуг
* Соглашений об уровне обслуживания (SLA)
* А также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Требования к процессу “Управление знаниями”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.5.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление знаниями”: Инициатор записи Базы знаний - любой пользователь системы, имеющий право доступа на создание записи в соответствующем реестре."
3.5.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись базы знаний с заполнением основной и подробной информации по установленной форме."
3.5.3, "Система должна позволять связывать запись базы знаний с зарегистрированными инцидентами и проблемами в соответствующих реестрах."
3.5.4, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей Базы знаний, а также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Требования к процессу “Управление конфигурациями”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.6.1, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Конфигурационную Единицу по установленной форме"
3.6.2, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех конфигурационных единиц. А также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Требования к процессу “Управление изменениями”
--------------------------------------------------------------------------------------------------------
.. csv-table::
:widths: 2, 30
3.7.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление изменениями”:
* Инициатор RFC - Любой сотрудник компании, являющийся автором и отправителем Заявки на изменение RFC
* Совет по изменениям (CAB) - группа пользователей, согласующими RFC или CR на разных этапах процесса.
* Эксперт - Сотрудник компании (н-р, сотрудник IT отдела) являющийся экспертом по данному вопросу из RFC, обладающие компетенциями чтобы провести оценку рисков, ресурсов, составить план работ и план отката.
* Менеджер SC- Сотрудник компании (н-р, руководитель IT отдела), распределяющий нагрузку среди исполнителей работ по изменениям, назначающий сроки исполнения этих работ. (управляет Графиком изменений)
* Исполнитель - Сотрудник, отвечающий за исполнение конкретной работы по плану реализации или плану отката CR"
3.7.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запрос на изменение (RFC) с заполнением следующей основной информации о запросе. А также дополнительной информации, позволяющей классифицировать данный запрос по важности/срочности, связывать запрос на изменение (RFC) с касающимися его услугами."
3.7.3, "Система должна позволять осуществлять процесс согласования запроса на изменения (RFC) с советом по изменения (CAB), а также с другимизаинтересованными лицами."
3.7.4, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа на основании запроса на изменение (RFC) запись об изменении CR: определять план реализации и план отката, а также необходимость включения в Релиз."
3.7.5, "Система должна позволять осуществлять маршрут согласования CR c советом по изменениям (CAB), а также другими заинтересованными лицами."
3.7.6, "Система должна позволять пользователю с ролью менеджер SC определять сроки исполнения работ по плану реализации и плану отката CR."
3.7.7, "Система должна позволять осуществлять координацию реализации работ по плану реализации и плану отката CR. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.7.8, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех запросов на изменения (RFC) и записей об изменении (CR), а также осуществлять поиск и фильтрацию по ключевым полям данных форм."
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment