Основания для разработки программы что это

Содержание

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

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

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

ПРИМЕР СОДЕРЖАНИЯ:

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

1.2 Область применения
Информатика 9 Этапы разработки программы Структура простой программы

ПРИМЕР СОДЕРЖАНИЯ:
Областью применения программного продукта является сфера деятельности федерального агентства «Государственные кадры».

1.3 Объект, в котором используют программу

ПРИМЕР СОДЕРЖАНИЯ:
АС ОВИР предлагается использовать в центральных и региональных департаментах и подразделениях агентства.

2 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

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

2.1 Документы, на основании которых ведется проектирование

ПРИМЕР СОДЕРЖАНИЯ (берется из ТЗ на АС в целом):
Основанием для разработки АС Кадры являются следующие документы и нормативные акты:
– Государственный контракт №1/11-11-11-001 от 11.11.2007 года на выполнение работ по выполнению первого этапа работ по созданию Единой автоматизированной системы учета кадров всех государственных предприятий «Кадры»;
– Федеральный закон от 01 июля 2006 г. N 555-ФЗ «Управление государственными кадрами»;
– Постановление Правительства РФ от 01 января 2000 г. N 11.11 «О федеральной целевой программе «Электронные кадры (2002 — 2009 годы)»;
– Концепция информатизации федерального агентства «Государственные кадры» на 2000-2010 годы.

2.2 Организация, утвердившая документ, и дата утверждения

ПРИМЕР СОДЕРЖАНИЯ:
Организация, утвердившая документ: Федеральное агентство «Государственные Кадры».
Адрес организации: 111000 г. Москва, Красная площадь, д.1.
Дата утверждения документа: 07.07.2007

2.3 Шифр темы

ПРИМЕР СОДЕРЖАНИЯ:
Шифр темы: АС-КА-ФА-07.

3 НАЗНАЧЕНИЕ РАЗРАБОТКИ

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

Алгоритм разработки программ

ПРИМЕР СОДЕРЖАНИЯ:
Открытый ведомственный информационный ресурс федерального агентства «Государственные Кадры» предназначен для Автоматизированная система Открытый ведомственный информационный ресурс (АС ОВИР) предназначена для обеспечения публичного доступа гражданам Российской Федерации к открытой части информации АС Кадры через Интернет. Также АС ОВИР должна обеспечивать доступ пользователей АС Кадры к операционным данным БД АС (путем предоставления сервисов, позволяющих формировать запросы на получение информации ограниченного доступа, в соответствии с уровнем компетентности пользователя).
Его функциями являются:
Предоставление публичного доступа к следующей информации:
— Новости ФА;
— Статистические данные и отчеты;
— Полный перечень документов, регламентирующих работу ФА и услуги, предоставляемые им;
— т.п.;
— пр.
Обеспечение возможности сотрудникам ФА получать доступ к служебной информации АС Кадры;
Обеспечение функций администрирования;
т.п.;
пр.

ГОСТы

Классификаторы ЕСКД
Перечень стандартов
ГОСТ 2.xxx (ЕСКД)
ГОСТ 6.ххх (УСД)
ГОСТ 15.ххх
ГОСТ 19.xxx (ЕСПД)
ГОСТ 24.xxx (ЕСС АСУ)
ГОСТ 34.ххх

Источник: www.rugost.com

ведение

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

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

Постановка задачи

Техническое задание

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

Основанием для разработки программы является задание, выданное на дипломную практику руководителем практики от КГК.

Наименование работы «Электронный учебник для распределительной станции FESTO».

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

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

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

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

«Электронный учебник для распределительной станции FESTO» позволяет быстро ознакомиться с большим количеством информации данной тематики.

Основные функции программы:

2. Показ изображений;

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

1. Работать с заданным алгоритмом функционирования;

2. Поддерживать диалоговый режим в рамках, предоставляемых пользователю возможностей;

3. Производить бесперебойную работу.

Условия эксплуатации и требования к составу и параметрам технических средств

Условия эксплуатации программы совпадают с условиями эксплуатации по ЭВМ IBM PC. Программа должна быть рассчитана на непрофессионального пользователя.

Минимальные требования к электронной вычислительной машине:

· Процессор: Intel Pentium III

· Частота: 900 MHz

· Оперативная Память: 128 Мб

· Клавиатура и мышь.

Рекомендуемые требования к Электронной вычислительной машине:

· Процессор: Intel Pentium IV

· Частота: 1200 MHz

· Оперативная Память: 256 Мб

· Клавиатура и мышь.

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

· Операционная Система: Windows 95 или выше

· Язык программирования: Borland Delphi 7

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

Программа поставляется на лазерном носителе информации.

Программная документация поставляется в электронном и печатном виде.

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

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

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

Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство системного программиста, руководство оператору, описание программы.

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

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

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

Таблица 1. Стадии и этапы разработки

Чем заканчивается работа

Срок исполнения, начало окончание

Анализ задания на технологической практике и подготовка раздела «Введение»

Написание раздела «Введение»

Подготовка раздела «Техническое задание»

Написание раздела «Техническое задание»

Подготовка раздела «Постановка задачи»

Написание раздела «Постановка задачи»

Разработка функциональной схемы модуля

Наличие функциональной схемы модуля

Готовая рабочая программа

Оформление контрольного примера

Наличие контрольного примера

Подготовка разделов «Заключение» и «Список

Наличие готовых разделов

Разработка презентационного материала

Презентационный материал, выполненный в виде слайдов

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

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

Обзор существующих решений

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

Выбор языка программирования

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

Visual Basic является продуктом многолетней эволюции языка Basic. В основном этот язык предназначен для создания программ, работающих в режиме диалога с пользователем, т.е. в визуальном режиме. По своей сложности и возможностям Visual Basic можно поставить на один ряд с Borland Delphi 7 или С ++.

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

Именно уникальность Borland Delphi 7 позволяет создавать серьезные полнофункциональные решения в сжатые сроки. Он, удобен по всем показателям как для новичков, так и для профессионалов. Новичкам он позволяет с небольшими затратами сил и времени создавать прикладные программы, которые внешне ничем неотличимы от программ, которые создали профессиональные специалисты.

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

Интегрированная среда разработки Borland Delphi 7 была выбрана для написания программного обеспечения в связи с тем, что в данной работе была поставлена задача разработки модуля в рамках проекта, ориентированного на использование Borland Delphi 7.

В отличии от языка Visual Basic 6.0, в Borland Delphi 7 есть возможность более удобной работы с текстовыми документами с меньшими затратами времени для редактирования, создания и выполнения различных операций с данными в текстовых документах, а также можно выполнить более удобный интерфейс для непрофессионального пользователя.

Источник: studbooks.net

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

Разработка ведется на основании следующих документов:

1. Данное техническое задание

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

Функциональное и эксплуатационное назначение программы:

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

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

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

Программа должна полностью поддерживать стандарты передачи гипертекста (HTTP) версий 1.0 и 1.1, утвержденные World Wide Web Consortium (W3C), а так же стандартные протоколы FTP, SSL, SMTP, POP3 и т.д.
Программа должна обеспечивать переносимость в рамках операционных систем семейства Windows. Стандарт, предназначенный для достижения переносимости программного обеспечения на уровне исходных кодов.
Программа должна работать по архитектуре «клиент-сервер», поддерживать несколько одновременных соединений.
Программа должна считывать основные настройки из конфигурационного файла, осуществлять это во время работы, без остановки передачи данных.
Конфигурационный файл должен быть легко читаем для человека, занимающегося администрированием proxy-сервера.
Программа должна выбирать подходящий вышестоящий proxy-сервер, на который следует перенаправить запрос в соответствии с его приоритетом, определенным в конфигурационном файле, и его текущим статусом (доступен или недоступен).
Программа должна осуществлять проверку вышестоящих proxy-серверов на работоспособность. Это должно осуществляться в фоновом процессе, без прерывания выполнения других операций передачи данных.
Программа должна поддерживать передачу нескольких запросов в рамках одного соединения (pipelining).
Программа должна вести журнал своей деятельности, куда будут сохраняться все сообщения об ошибках, нарушениях передачи и прочих проблемах.

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

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

Для эксплуатации разрабатываемого программного обеспечения необходимы Windows-совместимая операционная система (Windows 98, WinNT 4.0, WinNT 5.0, WinNT 5.1) и компьютер архитектуры, поддерживаемой этой ОС.
Необходим сетевой адаптер, обеспечивающий связь с Internet.

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

Источник: studfile.net

Стандарты и шаблоны для ТЗ на разработку ПО

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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 техническое задание должно включать следующие разделы:

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

ГОСТ 19

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

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

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

IEEE STD 830-1998

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

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

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

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

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

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

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

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. Характеристики пользователей

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

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

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

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

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

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

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

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

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

RUP

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

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

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

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

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

SWEBOK, BABOK и пр.

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

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

А как же Agile?

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

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

Заключение

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

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

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

Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
Правила составления Software requirements specification (читать вместе с комментариями)
Примеры ТЗ и другой документации по разработке АС для МЭР
ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

Источник: habr.com

Лекция 12 Разработка технического задания

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

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

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

1) устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных;

2) определяют перечень результатов, их характеристики и способы их представления,

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

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

Основные факторы, определяющие характеристики разрабатываемого программного обеспечения:

• исходные данные и требуемые результаты, которые определяют функции программы или системы;

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

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

В соответствии с ГОСТ 19.201 — 78 программный документ «Техническое задание» содержит следующие разделы.

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

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

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

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

5. Технико-экономическое обоснование.

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

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

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

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

• документы, на основании которых ведется разработка;

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

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

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

3. В раздел «Требования к программе или программному изделию» входят следующие подразделы:

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

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

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

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

• требования к маркировке и упаковке;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Стадии и этапы разработки описаны в учебном пособии А.В.Рудакова «Технология разработки программных продуктов».

7. «Порядок контроля и приемки» предполагает указание на виды испытаний и общие требования к приему работы.

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

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

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

• схемы алгоритмов, таблицы, описания, обоснования, расчеты и т,д.;

• другие источники разработки.

Источник: karpusheva.ru