Меню

Требования к программной документации пример

Оглавление:

Требования к программной документации пример

Сервис бесплатной оценки стоимости работы

  1. Заполните заявку. Специалисты рассчитают стоимость вашей работы
  2. Расчет стоимости придет на почту и по СМС

Номер вашей заявки

Прямо сейчас на почту придет автоматическое письмо-подтверждение с информацией о заявке.

Пример разработки технического задания на программный продукт

Министерство образования Российской Федерации

Московский государственный институт электронной техники

Кафедра информатики и программного обеспечения

УТВЕРЖДАЮ Зав. кафедрой ИПОВС,

д.т.н., проф._Гагарина Л. Г.

ПРОГРАММА СОРТИРОВКИ ОДНОМЕРНОГО МАССИВА Техническое задание на лабораторную работу

Руководитель, к.т.н., доцент_Петров А. А.

Исполнитель, студент гр. МП 33_Власов С. Е.

Рис. П2.1. Пример оформления титульного листа технического задания

на учебный программный продукт

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

  • 2. Основание для разработки
  • 2.1. Программа разрабатывается на основе учебного плана кафедры «Информатика и программное обеспечение вычислительных систем».
  • 2.2. Наименование работы:

«Программа сортировки одномерного массива».

  • 2.3. Исполнитель: компания Вез18оЙ.
  • 2.4. Соисполнители: нет.
  • 3. Назначение

Программа предназначена для использования школьниками при изучении темы «Обработка одномерных массивов» в курсе «Информатика».

  • 4. Требования к программе или программному изделию
  • 4.1. Требования к функциональным характеристикам
  • 4.1.1. Программа должна обеспечивать возможность выполнения следующих функций:
    • • ввод размера массива и самого массива;
    • • хранение массива в памяти;
    • • выбор метода сортировки;
    • • вывод текстового описания метода сортировки;
    • • вывод результата сортировки.
  • 4.1.2. Исходные данные:
    • • размер массива, заданный целым числом;
    • • массив.
  • 4.1.3. Организация входных и выходных данных

Входные данные поступают с клавиатуры.

Выходные данные отображаются на экране и при необходимости выводятся на печать.

4.2. Требования к надежности

Предусмотреть контроль вводимой информации.

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

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

Система должна работать на IBM-совместимых персональных компьютерах.

  • • тип процессора. Pentium и выше;
  • • объем оперативного запоминающего

устройства. 32 Мб и более;

• объем свободного места на жестком

  • • тип процессора. Pentium II 400;
  • • объем оперативного запоминающего

устройства. 128 Мб;

• объем свободного места на жестком

4.4. Требования к программной совместимости.

Программа должна работать под управлением семейства операционных систем Win 32 (Windows 95/98/2000/МЕ/ХР и т. и.).

  • 5. Требования к программной документации
  • 5.1. Разрабатываемые программные модули должны быть са-модокументированы, т. е. тексты программ должны содержать все необходимые комментарии.
  • 5.2. Разрабатываемая программа должна включать справочную информацию о работе программы, описания методов сортировки и подсказки учащимся.
  • 5.3. В состав сопровождающей документации должны входить:
  • 5.3.1. Пояснительная записка на пяти листах, содержащая описание разработки.
  • 5.3.2. Руководство пользователя.

Разработка ТЗ по ГОСТ 19 — разделы 4-8

ГОСТ 19.ххх на создание технического задания: .

    Структура документа (разделы 4-8):

4 ТРЕБОВАНИЯ К ПРОГРАММЕ

УКАЗАНИЯ ГОСТ:
Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
— требования к функциональным характеристикам;
— требования к надежности;
— условия эксплуатации;
— требования к составу и параметрам технических средств;
— требования к информационной и программной совместимости;
— требования к маркировке и упаковке;
— требования к транспортированию и хранению;
— специальные требования.

4.1 Требования к функциональным характеристикам

УКАЗАНИЯ ГОСТ:
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.

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

ПРИМЕР СОДЕРЖАНИЯ:
АС ОВИР должна выполнять следующие функции:
1. Функции для работы с гражданами РФ:
— Обеспечение доступа всех пользователей к общедоступным функциям и сведениям, опубликованным на сайте;
— Отображение сведений о федеральном агентстве;
— Отображение новостных, нормативно-правовых и других сведений в графическом виде, табличной и текстовой форме;
— Навигация по разделам сайта;
— Поиск по ключевым словам;
— Скачивание на компьютер пользователя и печать бланков документов, представляемых в федеральное агентство;
— Регистрация пользователей;
— Управление профилем.
2. Административные функции:
— т.п.;
— пр.
Точный состав сведений, размещаемых на сайте, и функций сайта будет определен и согласован с Заказчиком на этапе подготовки технического задания на разработку АС ОВИР.

4.2 Требования к надежности

УКАЗАНИЯ ГОСТ:
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

4.3 Условия эксплуатации

УКАЗАНИЯ ГОСТ:
В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

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

УКАЗАНИЯ ГОСТ:
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять из ТЗ на систему в целом (в части, необходимой для данной АС):
— Требования к техническому обеспечению.

4.5 Требования к информационной и программной совместимости

УКАЗАНИЯ ГОСТ:
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.

4.6 Требования к маркировке и упаковке

УКАЗАНИЯ ГОСТ:
В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

ПРИМЕР СОДЕРЖАНИЯ:
Требования не предъявляются.

4.7 Требования к транспортированию и хранению

УКАЗАНИЯ ГОСТ:
В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

ПРИМЕР СОДЕРЖАНИЯ:
Требования не предъявляются.

5 ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

УКАЗАНИЯ ГОСТ:
В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела необходимо взять из ТЗ на систему в целом:
8 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ.

6 ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ

УКАЗАНИЯ ГОСТ:
В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

ПРИМЕР СОДЕРЖАНИЯ:
Ориентировочная экономическая эффективность не рассчитываются.
Предполагаемая годовая потребность продукта — 100 сеансов в год.
Зарубежных и отечественных аналогов нет.

7 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ

УКАЗАНИЯ ГОСТ:
В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять из ТЗ на систему в целом (в части, необходимой для данной АС):
ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ.

8 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ

УКАЗАНИЯ ГОСТ:
В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела необходимо взять из ТЗ на систему в целом:
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ.

8.1 Виды испытаний

8.2 Общие требования к приемке работы

УКАЗАНИЯ ГОСТ:
В приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.

ПРИМЕР СОДЕРЖАНИЯ:
Требования не предъявляются.

Программная документация. Требования Единой системы программной документации. Привести примеры программных документов

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

1. Общим требованиям к программным документам.

Общие требования к оформлению программных документов устанавливает ГОСТ 19.105-78.

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

Титульная часть состоит из листа утверждения и титульного листа согласно ГОСТ 19.104-78.

Информационная часть состоит из аннотации и содержания. В аннотации указывают сведения о назначении документа и сжатое изложение его основной части.

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

– обозначения структурного элемента (номер раздела, подраздела);

– наименование структурного элемента;

– адрес структурного элемента на носителе данных (например, номер страницы, номер файла и т.д.).

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

2. Требованиям к описанию языка.

Требования к содержанию и оформлению программного документа по описанию языка (программирование, управление заданием, организация вычислительно­го процесса) устанавливает ГОСТ 19.506-79. При этом учитываются положения ГОСТ 19.105-78 «Общие требования к программным документам». Составление ин­формационной части (аннотации и содержания) является обязательным.

Описание языка должно содержать следующие разделы.

1. Общие сведения. Указывают назначение и дают описание общих характе­ристик языка, его возможностей, основных сфер использования и т.д.

2. Элементы языка. Дают описание синтаксиса и семантики базовых и составляющих элементов языка.

3. Способы структурирования программы. Указывают способы вызова процедуры, передачи управления и другие элементы структурирования программы.

4. Средства обмена данными. Указывают описание Языковых средств обмена данными (например, средства ввода-вывода, внутреннего обмена данными и т.д.).

5. Встроенные элементы. Дают описание встроенных в язык элементов (например, функции, классы и т.д.) и правила их использования.

6. Средства отладки программ. Указывают описание наличных средств отладки программ, семантику этих средств, рекомендации относительно их использования.

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

3. Требованиям к тексту и описанию программы.

Структуру и оформление текста программы устанавливают в соответствии с ГОСТ 19.105-78 «Общие требования к программным документам». Составление ин­формационной части (аннотации и содержания) является обязательным.

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

– символические записи исходными или промежуточными языками;

– символическое представление машинных кодов и т.д.

В символическую запись разделов рекомендуется включать комментарии, ко­торые могут отображать, например, функциональное ‘назначение, структуру (ГОСТ 19.401-78).

Описание программы должно содержать следующие разделы (ГОСТ 19.402-78):

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

2. Функциональное назначение. Указывают классы решаемых задач и (или) назначение программы и сведения о функциональных ограничениях программы.

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

4. Использованные технические средства. Перечисляют типы ЭВМ и устройства, используемые для работы программы.

5. Вызов и загрузка. Указывают способ вызова программы с соответствующе­го носителя данных, входные точки программы. Допускается указывать адреса загрузки, сведения об использовании оперативной памяти, объем программы.

Читайте так же:  Исковое заявление о продлении срока для вступления в наследство

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

7. Выходные данные. Указывают характер и организацию выходных данных, а также формат и способ кодирования выходных данных.

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

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

Требования к содержанию и оформлению программного документа «Пособие системного программиста» устанавливает ГОСТ 19.563-79. При этом учитываются положения ГОСТ 19.105-78 «Общие требования к программным документам». Составление информационной части (аннотации и содержания) является обязательным.

Пособие системного программиста должно содержать следующие разделы.

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

2. Структура программы. Указывают сведения о структуре программы, ее составные части и связи между ними и другими программами.

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

4. Проверка программы. Указывают описание способов проверки, позволяющие оценить работоспособность программы (контрольные примеры, методы прогона, результаты).

5. Сообщения системному программисту. Указывают тексты сообщений, выдаваемых в ходе выполнения настройки и т.п.

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

5. Требования к пособию программиста.

Требования к содержанию и оформлению «Пособия программиста» устанавливает ГОСТ 19.504-79. При этом учитываются положения ГОСТ 19.105-78 «Общие требования к программным документам». Составление информационной части (аннотация и содержание) является обязательным.

Пособие программиста должно содержать следующие разделы.

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

2. Характеристика программы. Описывают основные характеристики и особенности программы (временные характеристики, режим работы, средств контроля и т.д.).

3. Обращение к программе. Указывают описание процедур вызова программы (способы передачи управления и параметров данных и т.д.).

4. Входные и выходные данные. Представляют описание организации используемой входной и выходной информации.

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

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

6. Требования к ТЗ.

Порядок построения и оформления ТЗ на разработку программы или программного изделия устанавливает ГОСТ 19.201-78.

Техническое задание содержит следующие разделы.

1. Вступление. Указывают наименование, сжато характеризуют сферу использования программы (изделия) и объекта.

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

В этом разделе указывают:

– документ, на основании которого выполняется разработка;

– организации, утвердившие этот документ;

– наименование и (или) условное обозначение цели разработки.

3. Назначение разработки. Указывают функциональное и эксплуатационное назначение программы (изделия).

4. Требования к программе или программному изделию.

Этот раздел состоит из следующих подразделов:

– требования к функциональным характеристикам и надежности;

– требования к составу и параметрам технических средств, их информационной и программной совместимости;

– условия эксплуатации, специальные требования.

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

6. Технико-экономические показатели.

В этом разделе указывают:

– ориентировочную экономическую эффективность;

– предусмотренную потребность на год;

– экономические преимущества в сравнении с лучшими образцами (анало­гами).

7. Стадии и этапы разработки. Устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, кото­рые должны быть разработаны, согласованы и утверждены), а также термины разработки, определяют исполнителей.

8. Порядок контроля и приемки. Указывают виды испытаний и общие требования к приемке работ.

В приложениях к ТЗ в случае необходимости указывают:

– перечень научно-исследовательских и других источников и работ, обосновывающих разработку;

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

studopedia.org — Студопедия.Орг — 2014-2019 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.004 с) .

Примеры разработки программной документации

Столичный учебный центр
г. Москва

Техническое задание на разработку программы
«10-Страйк: Инвентаризация Компьютеров» для учета компьютеров сети предприятия «

1.1. Наименование программы

1.2. Назначение и область применения

2. Требования к программе

2.1. Требования к функциональным характеристикам

2.2. Требования к надежности

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

2.2.3. Отказы из-за некорректных действий пользователей системы 3. Условия эксплуатации
3.1. Климатические условия эксплуатации
3.2. Требования к квалификации и численности персонала
3.3. Требования к составу и параметрам технических средств
3.4. Требования к информационной и программной совместимости
3.4.1. Требования к информационным структурам и методам решения
3.4.2. Требования к исходным кодам и языкам программирования
3.4.3. Требования к программным средствам, используемым программой
3.4.4. Требования к защите информации и программ
3.5. Специальные требования
4. Требования к программной документации
4.1. Предварительный состав программной документации
5. Технико-экономические показатели
5.1. Экономические преимущества разработки
6. Стадии и этапы разработки
6.1. Стадии разработки
6.2. Этапы разработки
6.3. Содержание работ по этапам
7. Порядок контроля и приемки
7.1. Виды испытаний
7.2. Общие требования к приемке работы

1.1. Наименование программы

Наименование программы: «10-Страйк: Инвентаризация Компьютеров» для учета компьютеров сети предприятия «

1.2. Назначение и область применения

Программа «10-Страйк: Инвентаризация Компьютеров » предназначена для инвентаризации компьютеров в локальных сетях, она позволяет администраторам сетей создать и вести базу данных инвентаризации и учета компьютеров, комплектующих, программ и лицензий с возможностью просмотра и отслеживания конфигурации удаленных компьютеров. Также она позволяет вести учет аппаратного и программного обеспечения на них.

Основанием для разработки является договор № 1347 от 6 апреля 2016 года.

2. Требования к программе

2.1. Требования к функциональным характеристикам

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

1) Сбор информации в организации с любой структурой

1.1.Получение информации по различным группам данных (более 50) аппаратного и программного обеспечения;

1.2.Сбор информации с локального и удалённых компьютеров и смартфонов под управлением Windows (WMI, NetBios, реестр), Linux и MacOS (по SSH), Android (SSH);

1.3.Три способа сбора информации: WMI , агенты , клиенты .

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

2. Подготовка отчетности

2.1. Ведение базы данных компьютеров с созданием собственных полей по учёту данных о пользователе и инвентаризации;

Создание различных отчётов (более 70 шаблонов отчетов в форматах pdf, html, doc, xml (xls), xls, txt) по состоянию аппаратного и программного обеспечения в сети;

3. Оповещение об изменениях и обнаруженных проблемах

3.1.Контроль изменений аппаратного и программного обеспечения на компьютерах сети;

3.2.Оповещение об изменениях в конфигурациях на компьютерах;

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

Ведение диагностики S.M.A.R.T., определение состояния здоровья жестких дисков;

4. Учет приложений и лицензий

4.1.Учет лицензионной информации, учет закупок лицензионного ПО, обнаружение проблем, связанных с лицензионной политикой;

4.2.Менеджер приложений. Ведение черного и белого списков ПО, запрещенного и разрешенного. Отчеты по установкам ПО;

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

2.2. Требования к надежности

2.2.1 Требования к обеспечению надежного функционирования программы

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

а) организацией бесперебойного питания технических средств;

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

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

2.2.3. Отказы из-за некорректных действий пользователей системы

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

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

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

3.2. Требования к квалификации и численности персонала

С программой могут работать несколько администраторов c разграничением прав доступа.

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

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

а) задача поддержания работоспособности технических средств;

б)задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы;

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

д)выявление соответствия лицензионных ключей и серийных номеров программных продуктов,

е)выявление пользователей, нарушающих лицензионное соглашение, а также ведение учёта лицензий;

ж) добавление компьютеров из диапазона IP адресов и др;

3.3. Требования к составу и параметрам технических средств

Особых требований к составу и параметрам технических средств не предъявляется.

Успешно работает с базой более 10000 компьютеров.

3.4. Требования к информационной и программной совместимости

3.4.1. Требования к информационным структурам и методам решения

При использовании WMI для сбора информации с компьютеров и проведения инвентаризации, программа устанавливается только на компьютер администратора и не требует установки программ на компьютерах пользователей . Процесс сбора данных ведется в фоновом режиме, параллельно опрашиваются несколько компьютеров одновременно, освобождая время на просмотр данных и подготовку отчетов. Опрос ведется по протоколам WMI и SSH, позволяя опрашивать Windows, Linux и MacOS компьютеры, а также Android-устройства.

Импорт структуры организации осуществляется из Active Directory.

Для опроса компьютеров под управлением ОС Линукс можно использовать протокол SSH . На машинах должен стоять SSH -сервер.

Программа может работать с СУБД MS SQL, MySQL, Oracle . Поддерживаются российские СУБД Linter и Postgre.

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

Пользователи и администраторы работают с базой данных через Веб интерфейс.

Программа собирает данные с помощью технологии WMI.

Если применение WMI в сети по какой-либо причине невозможно (политика безопасности или Windows Home-версий), программа поддерживает еще два альтернативных способа сбора информации с компьютеров: с помощью агентов и клиентов. Клиенты позволяют опрашивать даже компьютеры без сети , а также командировочные ноутбуки.

3.4.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются.

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows Vista/7/8 /10.

3.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

3.5. Специальные требования

Программа должна обеспечивать одновременную работу нескольких администраторов и пользователей посредством Веб- интерфейса.

4. Требования к программной документации

4.1. Предварительный состав программной документации

Состав программной документации должен включать в себя:

4.1.1. техническое задание;

4.1.2. программу и методики испытаний;

4.1.3. руководство оператора;

5. Технико-экономические показатели

5.1. Экономические преимущества разработки

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

6. Стадии и этапы разработки

6.1. Стадии разработки

Разработка должна быть проведена в три стадии:

1. разработка технического задания;

2. рабочее проектирование;

6.2. Этапы разработки

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

1. разработка программы;

2. разработка программной документации;

3. испытания программы.

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

6.3. Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

определение и уточнение требований к техническим средствам;

определение требований к программе;

определение стадий, этапов и сроков разработки программы и документации на неё;

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

На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации. На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
а). разработка, согласование и утверждение и методики испытаний; b ). проведение приемо-сдаточных испытаний;

Читайте так же:  Расписка об авансе в получении денежных средств за квартиру

c )корректировка программы и программной документации по результатам испытаний.

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

7. Порядок контроля и приемки

7.1. Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний. Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

7.2. Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

ООО «Техническая документация»

разработка техдокументации

Как писать техническое задание на программу по ГОСТ 19.201-78?

В 2004 — 2005 годах был опубликован минимально необходимый набор «учебно-тренировочных» документов на программы, включающий техническое задание на программу по ГОСТ 19.201-78, программу и методику испытаний по ГОСТ 19.301-79, руководство оператора по ГОСТ 19.505-79. Этого достаточно для разработки программы, проведения испытаний и сдачи ее заказчику. Редакция от 20.06.2018.

Как писать техническое задание на программу по ГОСТ 19.201-78?

Создан 15.02.2010 15:50:53

Примечание от 11.06.2014 г. — Уважаемые дамы и господа! Наверное, в каждом втором-третьем из ваших технических заданий на программы, тем или иным образом оказавшихся в руках автора, содержатся аутентичные тексты из настоящей статьи. Это здорово и чертовски приятно, но следует учитывать тот факт, что прошло почти десятилетие с момента первой публикации статьи, а за это время многое изменилось, особенно в части нормативных документов. Из песни, конечно, слов не выкинешь, но настройтесь на креатив и выдумывайте какие-нибудь более современные ее аранжировки. И не забывайте о том, что это учебно-тренировочный, а не «боевой» документ.

Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом [из п. 1.1 ГОСТ 19.201-78]

Лист утверждения и титульный лист

Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать [из п. 1.2 ГОСТ 19.201-78]

Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.

Изменения и дополнения

Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. 1.3 ГОСТ 19.201-78]

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

Состав разделов технического задания

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

В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]

Любые манипуляции с разделами — строго по согласованию с заказчиком.

Содержание разделов

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

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

В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие [из п. 2.1 ГОСТ 19.201-78]

Основное правило работы с текстом – детализация, дробление текста на структурные единицы, — разделы, подразделы, пункты и подпункты, см. статью «Как писать техническое задание?!» Содержание документа будет иметь четкую структуру, способствующую легкому поиску требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:

Наименование программы

Наименование программы – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

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

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

Основания для разработки

В разделе «Основания для разработки» должны быть указаны:

  • документ (документы), на основании которых ведется разработка;
  • организация, утвердившая этот документ, и дата его утверждения;
  • наименование и (или) условное обозначение темы разработки.

[из п. 2.2 ГОСТ 19.201-78]

В подразделе следует привести сведения, содержащиеся в договоре между заказчиком и исполнителем.

Основание для проведения разработки

Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор утвержден Директором ФГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.

Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании – зависит от конкретного случая.

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

Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf». Условное обозначение темы разработки (шифр темы) – «РТФ-007»

Назначение разработки

В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия [из п. 2.3 ГОСТ 19.201-78]

Функциональное назначение

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

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

Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?

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

Применим формальный подход:

Эксплуатационное назначение

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

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

Требования к программе или программному изделию

Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

[из п. 2.4 ГОСТ 19.201-78]

Если существуют стандарты, содержащие общие (технические) требования к программе, системе или изделию, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.

Требования к функциональным характеристикам

В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п. [из п. 2.4.1 ГОСТ 19.201-78]

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

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

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

Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая действий оператора. Применение клише — шаблонного построения фраз — детально расписано в статье «Как писать техническое задание?!».

Требования к организации входных данных

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

Любой файл иного формата, но с расширением rtf, открываться не должен.

Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного носителя, отформатированного, к примеру, в формате ext3, открываться не должны.

Требования к организации выходных данных

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

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

Требования к временным характеристикам программы не предъявляются.

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

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

В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.) [из п. 2.4.2 ГОСТ 19.201-78]

Надежность – штука тонкая и очень опасная. Но перечень функций и видов их отказов, согласно п. 1.3.2. ГОСТ 24.701-86, обязан составить заказчик и согласовать с исполнителем.

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

Требования к обеспечению надежного (устойчивого) функционирования программы

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

  • организацией бесперебойного питания технических средств;
  • использованием лицензионного программного обеспечения;
  • регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
  • регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие компьютеpных виpусов.

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

Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТу) можно считать безотказное выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст сбоев, требования по надежности считаются выполненными.

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

Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.

Время восстановления после отказа

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

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

Отказы из-за некорректных действий оператора

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

Условия эксплуатации

В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала [из п. 2.4.3 ГОСТ 19.201-78]

Читайте так же:  Алименты расходы при усн

Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания.

Климатические условия эксплуатации

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

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести климатические испытания в полном объеме за счет исполнителя.

Много лет тому назад автор статьи, в силу молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал на климатику», причем «попал конкретно» (так, со слов Путина, выражается просвещенная интеллигенция), на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!

Примечание от 10.02.2011 г. — По иронии судьбы специалисты «Технической документации» не так давно снова «попали на климатику», а точнее — провели разработку программы и методики испытаний на воздействие внешних факторов, по данным и результатам испытаний подготовили протокол испытаний, открыв для себя еще одно направление деятельности. Не зря говорят, что история развивается по восходящей спирали.

Автор выражает искреннюю благодарность «тогдашнему» заказчику за хороший урок.

Требования к видам обслуживания

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

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

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

Требования к численности и квалификации персонала

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

Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:

  • задача поддержания работоспособности технических средств;
  • задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
  • задача установки (инсталляции) программы.

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

Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).

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

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

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

В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик [из п. 2.4.4 ГОСТ 19.201-78]

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

  • процессор Pentium-1000 с тактовой частотой, ГГц — 10, не менее;
  • материнскую плату с FSB, ГГц — 5, не менее;
  • оперативную память объемом, Тб — 10, не менее;
  • и так далее…

Требования к информационной и программной совместимости

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

При необходимости должна обеспечиваться защита информации и программ [из п. 2.4.5 ГОСТ 19.201-78]

Требования к информационным структурам и методам решения

Иформационная структура файла должна включать в себя текст, содержащий разметку, предусмотренную спецификацией формата rtf.

Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.

Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на языке C++. В качестве интегрированной среды разработки программы должна быть использована среда Borland C++ Buider.

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

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

Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

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

Требования к маркировке и упаковке

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78]

Программа поставляется в виде программного изделия — на дистрибутивном (внешнем оптическом) носителе (компакт-диске). Речь идет, разумеется, о маркировке и упаковке дистрибутивного носителя данных.

Требование к маркировке

Программное изделие должно иметь маркировку с обозначением товарного знака компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.

Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача исполнителя — прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).

Требования к упаковке

Упаковка программного изделия должна осуществляться в упаковочную тару предприятия-изготовителя (поставщика).

Именно предприятия-изготовителя (поставщика). Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель (поставщик) тары.

Условия упаковывания

Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.

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

Порядок упаковки

Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.

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

Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.

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

На верхний слой прокладочного материала укладывается товаросопроводительная документация — упаковочный лист и ведомость упаковки.

Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.

Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.

В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.

Габариты грузового места должны быть не более 1250 • 820 • 1180 мм.

Масса НЕТТО — не более 200 кг.

Масса БРУТТО — не более 220 кг.

Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком — полнейший стёб, но требования есть и остаются требованиями.

Требования к транспортированию и хранению

В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях [из п. 2.4.7 ГОСТ 19.201-78]

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

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

Условия транспортирования и хранения

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

При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания пыли и атмосферных осадков. Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже:

  • температура окружающего воздуха, °С — от плюс 5 до плюс 50;
  • атмосферное давление, кПа — такое-то;
  • относительная влажность воздуха при 25 °С — такая-то.

Специальные требования

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

Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.

Требования к программной документации

В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней [из п. 2.5а ГОСТ 19.201-78]

Предварительный состав программной документации

В состав программной документации должны входить:

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

Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]

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

Технико-экономические показатели

В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами [из п. 2.5 ГОСТ 19.201-78]

Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.

Как рассчитать экономическую эффективность? Следовало бы получить от заказчика цифры. Заказчик, в свою очередь, вряд ли заинтересован раскрывать свои финансовые дела. Скорее всего, вопрос отпадет сам собой.

Положим, заказчик оснащает программой десяток рабочих мест. Исполнитель потребовал за разработку $1000. Заказчик мог бы установить на рабочие места программный продукт третьей фирмы, стоимостью $500 за дистрибутив и по $100 за лицензию на каждое рабочее место.

Экономические преимущества разработки

Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:

Читайте так же:

  • Выписаться из квартиры тверь Как нужно действовать, чтобы выписать из квартиры человека, прописанного в ней? Снятие с регистрационного учета (выписка) жильцов из квартир как государственных, так и находящихся в частной собственности может быть добровольное или принудительное. Жилец выписывается сам, если […]
  • Как подать на алименты в браке на двоих детей Алименты на двоих детей Дети имеют установленное законодательством право на получение содержание от каждого из родителей (ст. 80 Семейного Кодекса (СК) РФ) для обеспечения их первоочередных потребностей, а также реализации воспитания и получения образования. Неважно, какое количество […]
  • Досрочная пенсия при ликвидации предприятия в 2019 году Досрочная пенсия безработному В условиях экономического спада работникам, потерявшим свое рабочее место, бывает нелегко снова найти рабочее место. Еще больше эта задача усложняется для людей предпенсионного возраста. В поисках нового трудоустройства призвана помочь биржа труда (Центр […]
  • Как возникает государственная собственность Как возникает государственная собственность Сервис бесплатной оценки стоимости работы Заполните заявку. Специалисты рассчитают стоимость вашей работы Расчет стоимости придет на почту и по СМС Номер вашей заявки Прямо сейчас на почту придет автоматическое письмо-подтверждение с […]
  • Пособия на 3 ребенка до 3 лет в москве Выплаты при рождении третьего ребенка в 2018 году в Москве Государственные пособия – это существенная помощь, тем более, для многодетных семей. Можно выделить три основных направления государственного финансирования: федеральные единовременные; федеральные ежемесячные; […]