Техническое задание на разработку автоматизированной системы

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам

• 1. Интерфейсы пользователя
• 2. Интерфейсы аппаратного обеспечения
• 3. Интерфейсы программного обеспечения
• 4. Интерфейсы взаимодействия

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

3. Требования к производительности

4. Проектные ограничения (и ссылки на стандарты)

5. Нефункциональные требования (надежность, доступность, безопасность и пр.)

6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

Мне же больше нравится адаптированный шаблон Карла Вигерса, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку вы уже несколько раз, надеюсь, перечитали.

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

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

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы

• 1. Содержание системы
• 2. Функции системы
• 3. Характеристики пользователей

4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

• 1. Назначение
• 2. Содержание (границы)

• 3. Обзор продукта
• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователей
• 4. Ограничения

4. Термины и определения

2. Ссылки

3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Описание файла

Файл "Пример 4" внутри архива находится в следующих папках: 1, examples. Документ из архива "ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы", который расположен в категории "разное". Всё это находится в предмете "проектирование по автоматизированных систем" из девятого семестра, которые можно найти в файловом архиве МЭИ (ТУ). Не смотря на прямую связь этого архива с МЭИ (ТУ), его также можно найти и в других разделах. Архив можно найти в разделе "остальное", в предмете "проектирование по автоматизированных систем" в общих файлах.

Онлайн просмотр документа "Пример 4"

Текст из документа "Пример 4"

ст. гр. 21612 — ИВТ

Распределённая система управления физическим экспериментом

наименование вида АС

Петрозаводский Государственный Университет

наименование объекта автоматизации

РС управления ФЭ

сокращенное наименование АС

Действует с __.__.2009г.

Д.ф-м.н., профессор кафедры ИИСиФЭ

1.1 Полное наименование системы и ее условное обозначение. 3

1.2 Наименование разработчика системы и реквизиты заказчика. 3

1.3. Основания для разработки АС. 3

1.4. Плановые сроки начала и окончания работы по созданию системы: 3

1.5. Источник финансирования работ по созданию АС. 3

1.6. Порядок оформления и предъявления заказчику результатов работ по созданию системы: 3

2. Назначение и цели создания системы 5

2.1 Назначение системы. 5

2.2 Цели создания системы. 5

3. Характеристика объекта автоматизации 6

3.1.Краткие сведения об объекте автоматизации. 6

3.2. Сведения об условиях эксплуатации объекта автоматизации. 6

4. Требования к системе 7

4.1. Требования к системе в целом. 7

4.1.1.Требования к структуре и функционированию системы 7

4.1.2. Требования к средствам и способам связи для информационного обмена между компонентами системы. 7

4.1.3. Требования к характеристикам взаимосвязи создаваемой системы со смежными системами, требования к ее совместимости. 8

4.1.4. Требования по диагностированию системы. 8

4.1.5. Перспективы системы, модернизация системы. 8

4.1.6. Требуемый режим работы персонала. 8

4.1.7. Требования к надежности комплекса. 8

4.1.8 Требования к численности и квалификации персонала программы и режимы его работы 9

4.1.9. Требования по безопасности системы. 9

4.1.10. Требования по эргономике и технической эстетике. 10

4.1.11. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению систем комплекса. 10

4.1.12. Требования по сохранности информации. 11

4.1.13 Требования к средствам защиты от внешних воздействий. 11

4.1.14 Требования к защите информации от несанкционированного доступа. 11

4.1.15. Требования по стандартизации и унификации. 12

4.2. Требования к задачам, выполняемым системой. 12

4.2.1 Перечень функций, подлежащих автоматизации: 12

4.3. Требования к видам обеспечения. 13

4.3.1. Требования к информационному обеспечению. 13

4.3.2. Требования к лингвистическому обеспечению. 14

4.3.3. Требования к программному обеспечению. 14

4.3.4. Требования к техническому обеспечению. 14

4.3.5 Требования к методическому обеспечению. 15

5. Состав и содержание работ по созданию системы 16

6. Порядок контроля и приемки системы. 17

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. 18

8. Требования к документированию. 19

Список источников 20

1.1 Полное наименование системы и ее условное обозначение.

Распределённая система управления физическим экспериментом.

Условное обозначение: РС управления ФЭ

1.2 Наименование разработчика системы и реквизиты заказчика.

Заказчик – кафедра ИИСиФЭ ПетрГУ

Разработчик – студент группы 21612 Когочев Антон Юрьевич.

1.3. Основания для разработки АС.

Работа по созданию распределённой системы управления физическим экспериментом.

1.4. Плановые сроки начала и окончания работы по созданию системы:

— начало работ по созданию системы – осень 2009

— окончание работ по созданию системы – конец весны 2010

1.5. Источник финансирования работ по созданию АС.

Собственные средства разработчика.

1.6. Порядок оформления и предъявления заказчику результатов работ по созданию системы:

К результатам труда разработчика относится:

оригинальное аппаратное обеспечение;

оригинальное программное обеспечение;

уникальные структуры данных;

типовые проектные решения и особенности построения распределённой системы;

проектная и рабочая документация.

! 2 диска с дистрибутивом программного обеспечения ИС учета и контроля ТВКР;

! 1 диск с демонстрационными примерами;

Заказчик приобретает у третьих лиц:

! лицензионное программное обеспечение.

Активное сетевое оборудование.

Пассивное сетевое оборудование

Результаты работы предоставляются заказчику:

Результаты передаются заказчику частями по завершении каждой стадии работы по созданию системы

Активное сетевое оборудование

Документация – в электронном виде в формате MS Word, на бумажных носителях.

Проектная документация должна быть разработана в соответствии с ГОСТ 34.201-89 и ГОСТ ЕСПД. Процедуры приемки — передачи результатов работ оформляются актами приемки-передачи.

2.1 Назначение системы.

ИС учета и контроля ТВКР предназначена для автоматизации создания, контроля, хранения, учета, изменения тем квалификационных работ.

2.2 Цели создания системы.

Целью создания системы является:

снижение рутинной работы преподавателям – руководителям ВКР, секретарю ГАК, а так же секретарю кафедры СУ и ВТ.

предоставление возможности преподавателям – руководителям ВКР отслеживания и контроля над ходом выполнения ВКР.

увеличить скорость доступа к информации связанной с ТВКР.

3.1.Краткие сведения об объекте автоматизации.

Объектом автоматизации является кафедра СУ и ВТ Калининградского Государственного Технического Университета (КГТУ). Основной деятельностью кафедры является обучение студентов.

3.2. Сведения об условиях эксплуатации объекта автоматизации.

ИС учета и контроля ТВКР используется преподавателями – руководителями ВКР, студентами – выпускниками, секретарем кафедры СУ и ВТ и секретарем ГАК.

Документация, связанная с ВКР разрабатывается каждый год, а именно:

приказы составляются весной, на каждого студента – выпускника, затем в течение года возможны изменения (объем приказа 1 лист А4 или );

отчеты ГАК и протоколы составляются на каждого студента – выпускника.

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

— при конструктивной температуре, давлении и допустимом уровне запыленности.

«Гигиенические требования к микроклимату производственных помещений ». Специалист выполняет соответствующие ему функции ежедневно (кроме субботы и воскресения) с 9.00 до 18.00 часов.

4.1. Требования к системе в целом.

4.1.1.Требования к структуре и функционированию системы

ИС учета и контроля ТВКР должна представлять собой систему, включающую в себя подсистемы:

п/с загрузки базы данных

п/с подготовки ВКР

п/с защиты и подготовки отчетности по ВКР.

П/с загрузки базы данных:

запускает Microsoft Access, загружает mdb-файл базы данных.

считывает информацию о существующих объектах и связях между ними.

П/с выбора ВКР выполняет следующие функции:

определение и учет ТВКР;

поиск и выявление совпадающего названия темы;

корректировка и внесение в название темы

П/с подготовки ВКР выполняет следующие функции:

контроль выполнения графика работы над проектом

график защиты ВКР

П/с защиты и подготовки отчетности по ВКР выполняет следующие функции:

отчетности секретаря ГАК.

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

Для информационного обмена между компонентами системы должна быть организована локальная сеть. ИС учета и контроля ТВКР функционирует на сервере, к которому имеют доступ пользователи этой программой по средствам локальной сети.

4.1.3. Требования к характеристикам взаимосвязи создаваемой системы со смежными системами, требования к ее совместимости.

ИС учета и контроля ТВКР будет использоваться преподавателями – руководителями ТВКР, студентами – выпускниками ВКР кафедры СУ и ВТ, секретарем ГАК и секретарем кафедры СУ и ВТ. Обмен информацией между компонентами системы и преподавателями/студентами/секретарем ГАК/секретарем кафедры должен производиться путем передачи электронных документов и иной информации.

4.1.4. Требования по диагностированию системы.

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

4.1.5. Перспективы системы, модернизация системы.

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

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

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

4.1.6. Требуемый режим работы персонала.

Требуемый режим работы персонала – полный рабочий день с 9:00 до 18:00.

Основной перерыв должен составлять 1 час.

4.1.7. Требования к надежности комплекса.

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

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

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

неверные действия персонала компании;

пожар, взрыв и т.п.

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

сложные формы взаимосвязи систем комплекса;

существенная роль временных соотношений отказов отдельных систем комплекса;

разнообразные законы распределения среднего времени безотказной работы и восстановления.

4.1.8 Требования к численности и квалификации персонала программы и режимы его работы

Для работы с ИС необходимо разделение пользователей на:

пользователь – студент — выпускник (имеет возможность получения информации связанной с ТВКР и сроками сдачи);

пользователь – секретарь ГАК (имеет возможность заполнять, вносить изменения в подсистему программы связанную с защитой и подготовкой отчетности);

пользователь – секретарь кафедры СУ и ВТ (имеет возможность заполнять, добавлять данные связанные с ТВКР);

администратор – специалист, имеющий возможность корректировки информации в БД, вести профилактические мероприятия, следить за правильностью ведения БД.

пользователь – преподаватель – руководитель ВКР (может изменять, вносить корректировки в название ТВКР).

Квалификация пользователя программы:

Пользователь программы должен владеть навыками работы с операционной системой Microsoft Windows 2000/XP/Vista.

4.1.9. Требования по безопасности системы.

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

СаНПиН 2.2.4/2.8056-96 «Электромагнитные излучения радиочастотного диапазона»

ГОСТ Р. 50377-92 (МЭК 950-86) «Безопасность оборудования информационной технологии, включая электрическое конторское оборудование»

ГОСТ 27954-88 «Видеомониторы персональных вычислительных машин. Типы, основные параметры, общие технические требования»

ГОСТ 27201-87 «Машины вычислительные электронные персональные. Типы, основные параметры, общие технические требования»

4.1.10. Требования по эргономике и технической эстетике.

Видеотерминал должен соответствовать следующим требованиям:

экран должен иметь антибликовое покрытие;

цвета знаков и фона должны быть согласованы между собой;

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

необходимо регулярное обслуживание терминалов специалистами.

4.1.11. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению систем комплекса.

Необходимо выделять время на обслуживание и профилактику аппаратных систем комплекса (1 день в месяц).

Сеть энергоснабжения должна иметь следующие параметры: напряжение – 220В; частота – 50Гц.

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

Специалист по сетевым технологиям с высшим образованием должен проводить обслуживание программных систем комплекса в следующих случаях: выход из строя программных систем; при неправильном использовании программных систем; по плану 1 день в месяц для проведения тестирования программных систем.

4.1.12. Требования по сохранности информации.

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

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

— стихийные бедствия (пожар, наводнение, взрыв, землетрясение и т.п.);

— хищение носителей информации, других систем комплекса;

В данной статье приведен пример (образец) проектного документа «Техническое задание на создание автоматизированной системы (АС)» согласно ГОСТ 34.602-89. В качестве примера АС для заполнения разделов использовались требования на разработку информационно-аналитической системы «Корпоративное хранилище данных».

Разделы технического задания:

Назначение и цели создания системы

Цели создания системы

Характеристика объектов автоматизации

Требования к системе

Требования к системе в целом

Требования к функциям, выполняемым системой

Требования к видам обеспечения

Состав и содержание работ по созданию системы

Порядок контроля и приёмки системы

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Требования к документированию

Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных»

1. Общие сведения

1.1. Наименование системы

1.1.1. Полное наименование системы

Например: Полное наименование: Корпоративное хранилище данных.

1.1.2. Краткое наименование системы

Например: Краткое наименование: КХД, Система.

1.2. Основания для проведения работ

Перечень документов, на основании которых создается система, кем и когда утверждены документы. Указывается шифр темы или шифр (номер) договора, дата договора.

Например: Работа выполняется на основании договора № … от … между …

1.3. Наименование организаций – Заказчика и Разработчика

Заказчик: ОАО Заказчик Адрес фактический: г. Москва . Телефон / Факс: +7 (495) 2222222

Разработчик: ЗАО Разработчик Адрес фактический: г. Москва . Телефон / Факс: +7 (495) 3333333

1.4. Плановые сроки начала и окончания работы

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

1.5. Источники и порядок финансирования

Если не целесообразно указывать эти сведения, то дается ссылка на Договор.

1.6. Порядок оформления и предъявления заказчику результатов работ

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

Например: Работы по созданию КХД сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

2. Назначение и цели создания системы

2.1. Назначение системы

Указать вид автоматизируемой деятельности (указать для управления какими процессами предназначена система). Указать перечень объектов автоматизации, на которых предполагается использовать систему, перечень автоматизируемых органов (пунктов) управления объекта автоматизации и управляемых ими объектов (здесь указать в каких подразделениях предусматривается устанавливать систему и привести в разрезе подразделений перечень автоматизируемых бизнес-процессов верхнего уровня).

КХД предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика. Основным назначением КХД является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика. В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах: 1. анализ финансово-хозяйственной деятельности; 2. информационная поддержка процессов бюджетирования; 3. .

Поделитесь ссылкой пожалуйста: