Учебное пособие: «Экономика, разработка и использование программных средств»

Министерство образования Российской Федерации ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ УПРАВЛЕНИЯ

Институт информационных систем управления Кафедра компьютерных технологий

Утверждено

первым проректором ГУУ

проф. Ю.Л. Старостиным

11 мая 2001 г.

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

к курсовому проектированию по дисциплине

Москва — 2001

для студентов специальности «Информационные системы в управлении» — 071900

УДК 681.3.06 6Н1

Методические указания к курсовому проектированию по дисциплине «Экономика, разработка и использование программных средств» / Сост.: Л.Б. Венчковский, И.Т. Рудник; ГУУ. М., 2001. — 36 с.

Составители кандидат технических наук, доцент

Л.Б. ВЕНЧКОВСКИЙ

кандидат экономических наук, доцент

И.Т. РУДНИК

Ответственный редактор

заведующий кафедрой компьютерных технологий,

кандидат экономических наук, доцент

В.А. МАШУРЦЕВ

Рецензент

доцент кафедры информационных систем ГУУ,

кандидат экономических наук

Н.М. ЛОБАНОВА

1. Введение

Настоящие методические указания предназначены для проведения курсового проектирования, выполняемого студентами 3-го курса специальности 071900 «Ин-срормационные системы в управлении» по дисциплине «Экономика, разработка и использование программных средств ». После перехода на новый образовательный стандарт методические указания могут быть использованы в качестве учебного пособия при выполнении лабораторных работ студентами специальности 351400 «Прикладная информатика в управлении» по дисциплине «Разработка и стандартизация программных средств и инсрормационных технологий».

Курсовое проектирование осуществляется в 6-м, завершающем для данной дисциплины, семестре.

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

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

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

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

В свою очередь, описываемое курсовое проектирование закладывает определенные основы для следующих дисциплин: «Мировые информационные ресурсы и сети», «Защита информации и информационная безопасность», «Автоматизированные информационные системы», «Проектирование автоматизированных экономических информационных систем».

2. Общие требования к курсовому проекту

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

1. Система контроля за исполнением документов для организации.

2. Система заказа билетов на авиарейсы.

3. Система обслуживания клиентов сберегательного банка.

4. Система расчета размера пенсии и ведения пенсионных дел.

5. Автоматизированная система обработки кадровой информации.

6. Система библиотечного обслуживания.

7. Система бронирования мест в гостиницах города.

8. Справочная система метрополитена.

9. Система банковского кредита.

10. Система обработки заказов в магазине.

11. Система ведения кредитных карточек.

12. Система оптовой торговли по заявкам.

13. Система выплат гонораров авторам произведений.

14. Система обмена коммерческой информацией.

15. Системы вычисления налогов работников бюджетной сферы.

16. Система учета и управления кадрами.

17. Система расчета заработной платы при повременной и тарифно-
квалификационной оплате.

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

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

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

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

зом:

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

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

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

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

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

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

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

Система должна включаться в АРМ менеджера турфирмы, осуществляющего работу с клиентами.

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

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

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

Ориентировочный объем курсового проекта (пояснительной записки) — 100 страниц.

Общие требования к содержанию и оформлению пояснительной записки :

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

— связь входов и выходов системы с основными процессами (операциями)
обработки данных может показываться с помощью схем Н1РО;

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

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

— логическая схема создаваемой базы данных может быть представлена в
виде ЕВ-диаграммы;

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

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

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

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

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

— тексты исходных модулей должны быть документированы и содержать
комментарии;

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

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

• словарь типов данных системы должен содержать не менее 3-4-х статей.
Исходными данными для каждого проекта служат конкретные характеристики

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

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

3. Содержание курсового проекта

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

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

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

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

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

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

(^^Архитектура программного комплекса на уровне физической модели совокупности модулей, реализующих программное изделие.

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

\^ /ЗЛГДокументированные тексты программных модулей и программы на магнитном носителе. База данных должна содержать не менее 50 записей каждого типа.

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

Гб/Руководство пользователя программного изделия.

(При м е ч а н и е. Подробное описание содержания работ и основных документов представлено в приложении 1.

4. Организация курсового проектирования

При выполнении данного курсового проекта используется бригадная форма организации работ, являющаяся в практике разработки программных изделий общепринятой и наиболее эффективной. Каждая бригада (2-3 студента) получает отдельное задание согласно выбранной теме (список тем приведен в разделе 1); тема может быть предложена и студентами с обоснованием целесообразности ее разработки. Работу бригады возглавляет главный программист, остальные выполняют роль программистов, на одного из членов бригады возлагается роль секретаря (библиотекаря). За каждым членом бригады закрепляется выполнение конкретных работ и оформление соответствующей системной и пользовательской документации.

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

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

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

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

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

Учитывая большой объем работ по программированию, отладке и тестированию необходимых программных модулей, отдельные задания на лабораторные работы в 6-м семестре не выдаются. Лабораторные работы выполняются и защищаются как промежуточные этапы курсового проекта. Отладка программ и их компоновка проводятся на ПЭВМ во время, выделенное для лабораторных работ, в присутствии преподавателя.

Дополнительное машинное время для курсового проектирования выделяется группам по соответствующим заявкам. В это время студенты работают самостоятельно, без преподавателя.

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

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

График выполнения курсового проекта ( перечень работ )

Завершение работы (неделя)	Содержание работ
2	Уточнение и согласование исходного задания.
4	Анализ предметной области и документопотоков в системе, спецификация требований пользователя.
5	Определение требований к программному изделию.
6	Технико-экономическое обоснование и оценка осуществимости концепции выбранной информационной системы, определение трудозатрат на разработку.
•: .-•:; 7	Системный структурный анализ потоков данных, определение архитектуры программного комплекса, структуры и содержания базы данных.
: .8 • -•••••'-' •	Разработка и утверждение технического задания.
9	Разработка архитектуры программного комплекса, алгоритмов и спецификаций программных модулей.
10	Кодирование и автономная отладка программных модулей.
11	Оформление «Руководства пользователя».
12	Подготовка «Плана приемо-сдаточных испытаний».
14	Комплексная отладка программного изделия и оформление контрольного примера.
16	Оформление пояснительной записки и сдача ее на проверку.
17	Приемо-сдаточные испытания программного изделия и защита курсового проекта.

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

5. Оформление результатов

К представляемым руководителю основным составляющим курсового проекта относятся:

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

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

— титульный лист;

— оглавление;

— задание на курсовое проектирование;

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

— технико-экономическое обоснование осуществимости и целесообразности
создания планируемой системы,

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

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

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

— функциональная архитектура программной системы;

— алгоритмы модулей в виде схем действий;

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

— документированные тексты исходных программных модулей;

— план приемо-сдаточных испытаний программного изделия;

— результаты тестирования (прогона контрольного примера);

— расчет экономической эффективности;

— руководство пользователя;

— другие документы (по согласованию с преподавателем);

— список использованной литературы;

— приложения (например, словарь системы).

При оформлении курсового проекта необходимо руководствоваться следующим:

— все материалы оформляются на бумаге стандартного формата А4 на одной
стороне, рукописно или машинописно, с оставлением полей, все страницы должны
быть пронумерованы;

— в случае набора пояснительной записки на компьютере рекомендуется
шрифт №№ 12, 14, формат набираемого материала 17,5 х 24 см (длина строки, вы
сота печатаемого текста), поля: левое — 2 см, правое — 2 см, верхнее — 2 см, нижнее
— 2 см;

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

— каждое приложение должно снабжаться заголовком вида: слово
«ПРИЛОЖЕНИЕ», его порядковый номер и наименование, отражающее содержание
данного приложения;

— титульный лист курсового проекта должен соответствовать типовой форме
(см. прилож. 2).

6. Организация защиты

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

К подобным промежуточным материалам относятся:

— технико-экономическое обоснование целесообразности разработки систе-

мы;

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

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

логическая схема базы данных;

словарь системы;

демонстрация работы ядра (прототипа) системы;

спецификации модулей системы;

демонстрация работы отдельных модулей;

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

расчет экономической эффективности;

отдельные проектные и эксплуатационные документы;

план приемо-сдаточных испытаний.

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

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

Подведение итогов курсового проектирования включает следующие этапы:

— сдача курсового проекта (пояснительной записки) на проверку руководителю;

— проведение приемо-сдаточных испытаний системы;

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

— сдача готового курсового проекта;

— защита курсового проекта.

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

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

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

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

Оценка проекта производится с учетом:

— соответствия продемонстрированных на испытаниях возможностей систе
мы требованиям, зафиксированным в техническом задании;

— полноты и качества разработанных проектных и эксплуатационных доку
ментов;

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

— исполнения требований госстандартов и кафедры к оформлению поясни
тельной записки;

— практической полезности разработанной системы;

— качества ответов на вопросы при защите.

ЛИТЕРАТУРА

1. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с
англ. — М.: Радио и связь. 1985. — 512 с.

2. Венчковский Л.Б. Разработка сложных программных изделий: Учеб. Посо
бие для вузов / Под ред. В.А. Машурцева; ГУУ.- М.: ЗАО «Финстатинформ», 1999.-
109с.

3. Гейн К., Сарсон Т. Структурный системный анализ: средства и методы: Пер.
с англ. Ч. 1,2. — М.: «Эйтекс», 1993.

4. Липаев В.В. Документирование и управление конфигурацией программных
средств. Методы и стандарты. Серия «Информатизация России на пороге XXI века».-
М.: СИНТЕГ, 1998.-220с.

5. Липаев В.В. Системное проектирование сложных программных средств для
информационных систем. Серия «Информатизация России на пороге XXI века».- М.:
СИНТЕГ, 1999.-224с.

6. Человеческий фактор: Пер. с англ… (т. 6. Эргономика в автоматизированных
системах). — М.: Мир, 1992.

Приложение 1

1. Содержание работ по курсовому проектированию

1.1. Общие замечания

Работы по курсовому проектированию проводятся в соответствии с этапами жизненного цикла программного изделия (ЖЦПИ) и характеризуются последовательным уточнением принимаемых проектных и управленческих решений. Это означает, что процесс разработки принципиально является итерационным как в части планов, так и в определении функций системы, показателей качества, архитектуры программного объекта.

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

13О 12207: 1995. Процессы жизненного цикла программных средств.

18О 9000-3: 1991. Общее руководство качеством и стандарты по обеспечению качества.

15О 9126: 1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению.

Укрупненно этапы ЖЦПИ (при использовании каскадной модели) включают:

• определение требований пользователя (заказчика);

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

• архитектурное проектирование программного изделия;

• детальное проектирование программного изделия;

• изготовление программного изделия;

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

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

• определение потребностей заказчика;

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

• технико-экономический анализ альтернативных вариантов и обоснование
выбора автоматизированной информационной системы;

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

• распределение функций между элементами системы и между ее подсисте
мами;

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

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

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

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

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

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

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

Все требования пользователей удобно разделить на две группы.

1. Требования, отражающие возможности системы, реализация которых обес
печивает решение поставленной проблемы.

2. Требования, определяющие ограничения на способы и пути решения про
блемы или на пути достижения поставленной цели.

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

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

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

1. Идентификатор, позволяющий проследить выполнение каждого ус
тановленного требования через все фазы ЖЦПИ.

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

3. Стабильность требования, указывающая степень его постоянства на
протяжении ЖЦПИ. При этом должны быть отмечены те требования, которые могут
быть изменены в результате получения в процессе проектирования новой информа
ции или в результате накопления опыта эксплуатации.

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

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

6. Проверяемость требования, предполагающая, что каждое требова
ние должно поддаваться проверке выполнения. Это необходимо для возможного
контроля того, что требование включено в проект и реализовано программными
средствами и для тестирования этого требования.

7. Ясность формулировки, означающая определенность и однозначность
требования и отсутствие какой-либо неопределенности,

1.3. Анализ осуществимости разработки программного изделия
Одновременно с исследованием существующей информационной системы и

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

1.4. Определение требований к программному изделию
1.4.1. Основные виды деятельности

Второй фазой ЖЦПИ является фаза определения требований к программному изделию, которая является фазой «анализа проблемы». Главной целью этой фазы является разработка полной, непротиворечивой и корректной совокупности требований к программному обеспечению на основе всестороннего изучения требований пользователя. За выработку этих требований всегда отвечает разработчик. В качестве участников этой фазы должны привлекаться пользователи, инженеры-программисты, специалисты по техническим средствам, а также обслуживающий персонал. Ответственным за выполнение этой работы, как правило, назначается системный аналитик. Руководитель проекта организует взаимные консультации и обсуждения, поскольку участники этих обсуждений могут иметь разное представление о конечном продукте и их взгляды должны синтезироваться в четкие и непротиворечивые формулировки требований.

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

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

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

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

1.4.2. Разработка логической модели программного изделия

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

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

Логическая модель должна удовлетворять следующим правилам:

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

2. Функции должны соответствовать уровню иерархии, на котором они пред
ставлены в модели.

3. Связи между функциями (функциональными блоками модели) должны быть
минимизированы.

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

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

6. Для каждой функции должны быть указаны входные данные.

7. Каждой функции должен соответствовать список выходных данных (выход
ных отчетов).

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

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

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

Количественные требования не должны фиксироваться в виде качественных характеристик типа «быстрый ответ», а должны быть записаны, например, в виде «время ответа должно быть не более X сек», или вместо «в большинстве случаев» должно быть указано «для У% случаев среднее время ответа должно быть менее 2 сек» и т. п.

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

3. Требования к интерфейсам. Эти требования описывают эле
менты технических средств, программного обеспечения, баз данных, с которыми
должен взаимодействовать программный продукт. Требования к интерфейсам с тех
ническими средствами могут определять необходимую их конфигурацию. Требова
ния к программному обеспечению могут включать требования к типу и версии опе
рационной системы, прикладным пакетам, типу СУБД. Требования к внешним ин
терфейсам могут потребовать, например, использования конкретного сетевого про
токола передачи информации, определенного языка описания документов и т.п.

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

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

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

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

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

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

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

9. Требования к надежности. Они определяются либо значением
допустимого среднего времени между отказами, либо значением минимального
времени между отказами.

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

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

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

12. Требования к документации. Они обычно дополняют требо
вания, содержащиеся в стандартах на документацию.

1.4.4. Атрибуты требований к программному изделию

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

1) идентификатор, обеспечивающий возможность контроля реализа
ции этого требования в течение всех фаз ЖЦПИ;

2) уровень важности, указывающий, насколько существенным явля
ется это требование, может ли оно в дальнейшем обсуждаться и изменяться или же
оно является категорическим;

3) приоритет, указывающий некоторый порядок очередности в выполне
нии этого требования при планировании работ и при проектировании изделия;

4) стабильность, отражающая степень постоянства требования. Долж
ны быть отмечены все те требования, которые могут быть изменены на протяжении
ЖЦПИ в результате получения дополнительной информации об изделии;

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

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

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

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

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

1.4.5. Документ «Требования к программному изделию»

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

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

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

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

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

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

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

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

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

1.5. Архитектурное проектирование программного изделия

1.5.1. Общее содержание работ фазы

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

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

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

Рассматриваемая фаза ЖЦПИ заканчивается формальным утверждением документа «Архитектурный проект» после всестороннего его рассмотрения и критического обзора.

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

— конструирование физической модели программного изделия;

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

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

— обзор проекта.

1.5.2. Конструирование физической модели

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

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

1.5.3. Декомпозиция программного изделия на компоненты

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

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

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

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

1.5.4. Критерии качества архитектурного проекта

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

Простота формы достигается в результате:

— минимизация «сцепления» между компонентами;

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

— согласования программного обеспечения со структурами данных;

— максимизации числа компонент, использующих данную компоненту;

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

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

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

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

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

Документ «Архитектурный проект» программного изделия является ключевым документом, суммирующим все принятые решения. Он является основой для детального проектирования. Кроме описания всех компонент изделия, он должен содержать ссылки на все внешние интерфейсы. Одним из основных требований к до-

, 20

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

1.6. Детальное проектирование и изготовление программного изделия

1.6.1. Основные виды деятельности

Фаза детального проектирования и изготовления может быть названа «фазой реализации» в ЖЦПИ. Цель этой фазы — детализация проекта, описанного в предыдущем документе, она включает кодирование, тестирование и документирование. Ответственными за выполнение работ в этой фазе являются программисты, специалисты другого профиля подключаются для консультаций. Верификация программного изделия может проводиться независимо специалистами, не принимавшими участия в разработке.

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

Деятельность во время этой фазы должна выполняться в соответствии с планом, принятым на предыдущей фазе. Выполнение пунктов плана должно тщательно отслеживаться и документироваться.

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

— нисходящая декомпозиция;

— структурное программирование;
-одновременное изготовление и документирование.

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

Нисходящая декомпозиция жизненно важна для управления сложностью и для реализации принципа «сокрытия информации».

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

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

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

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

— начинаем с функциональной спецификации и спецификации интерфейсов;

— концентрируем внимание на потоках управления;

— откладываем объявление данных до фазы кодирования;

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

— проводим обзор каждого шага после его выполнения.

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

1.6.2. Кодирование модулей

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

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

— наименования программ, подпрограмм, файлов, переменных;

— ограничения размеров модулей;

— использования библиотек;

— определения констант;

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

— обработки ошибок и т.п.

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

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

Код должен быть структурным, так как это уменьшает ошибки и улучшает со-провождаемость.

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

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

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

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

1.6.3. Тестирование программного изделия

Процесс тестирования включает несколько этапов: поблочное тестирование, комплексное тестирование и системное тестирование.

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

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

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

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

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

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

Системное тестирование — это процесс тестирования интегрированного программного изделия. Этот этап тестирования может быть выполнен в процессе разработки или в условиях моделирования эксплуатации. Системное тестирование должно подтверждать соответствие разработанного программного изделия целям, установленным в документе «Требования пользователя».

Системное тестирование включает такие виды деятельности:

— передача данных в систему, корректность обработки данных и вывод резуль
татов;

— прогон тестов с целью проверки выполнения требований пользователя;

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

— предварительная оценка надежности и пригодности к сопровождению;

— проверка правильности «Руководства пользователя».

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

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

1.6.4. Документирование работ по проектированию программного изделия

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

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

Часть 2 документа постепенно расширяется по мере разработки проекта.

Часть 2 документа постепенно расширяется по мере разработки проекта. Структура этой части документа и идентификация разделов должна полностью соответствовать программным компонентам программного изделия.

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

2. Техническое задание на разработку программного изделия

2.1. Общие замечания

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

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

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

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

2.2. Оглавление технического задания

Титульный лист

Введение

1. Наименование разработки

2. Цель разработки

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

4. Используемая терминология предметной области

5. Перечень используемых сокращений

6. Описание проблемы автоматизации

6.1. Описание технологических процессов, подлежащих автоматизации.

6.2. Описание документооборота существующего технологического про
цесса.

6.3. Формулировка проблемы и задач автоматизации (требования поль
зователя).

7. Схемы потоков данных рассматриваемой проблемной области

8. Функциональное назначение разрабатываемого программного изделия
(требования к программному изделию)

х / 9. Архитектура программного комплекса и функциональная модель

10. Логическая схема базы данных

10.1. Диаграмма взаимосвязей данных (типа «сущность-отношение»)

10.2. Структура записей файлов (таблиц)

10.3. Словарь данных

11. Состав и привилегии пользователей, распределение функций между ними

12. Требования к интерфейсу пользователя

13. Структура меню программной системы

14. Детальное описание программных модулей

'/ ( 14.1. Описание алгоритма функционального модуля

14.2. Описание экранных форм, входных и выходных данных

15. Представление справочной инсрормации и выходные отчеты

16. Средства обеспечения защиты и безопасности программ и данных

17. Технические и программные средства

18. Рекомендации по распространению программного изделия.

Приложения

1. Технико-экономическое обоснование разработки

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

3. Перечень разрабатываемой документации

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

Введение

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

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

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

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

1. Наименование разработки

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

2. Цель разработки

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

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

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

4. Используемая терминология предметной области

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

5. Перечень используемых сокращений

Приводится список всех сокращений, используемых в ТЗ, и дается их расшифровка.

6. Описание проблемы автоматизации

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

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

6.2. Описание документооборота существующего технологического процесса
Приводится описание всех входных, промежуточных и выходных документов,

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

При описании документопотоков необходимо указать:

• источник поступления документа;

• способ передачи документа (бумажный носитель, факс, электронная почта,
сеть и т.д.);

• структура формы документа;

• информационное содержание документа;

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

• алгоритмы и результаты обработки документа;

• случаи одновременной (параллельной) обработки документов;

• форма передачи документа и приемник документа.

6.3. Формулировка проблемы и задач автоматизации (требования пользователя)

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

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

7. Схемы потоков данных рассматриваемой проблемной области

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

8. Функциональное назначение разрабатываемого программного изделия
(требования к программному изделию)

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

Как правило, описание функций систематизируется по следующим разделам:

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

• диалоговое взаимодействие с пользователями;

• управление базой данных;

• решение функциональных расчетных задач;

• представление информации пользователю в режиме выдачи регламентных
отчетов и в интерактивном запросном режиме;

• архивирование данных и формирование статистики;

• обеспечение защиты и безопасности данных;

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

1. Эксплуатационные требования.

2. Требования к интерфейсам.
3- Операционные требования.

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

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

6. Требования к качеству программного изделия.

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

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

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

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

10. Логическая схема базы данных

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

10.1. Диаграмма взаимосвязей данных (типа «сущность-отношение»)
Приводится общая схема данных в виде блок-схем (диаграмм), элементами

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

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

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

10.2. Структура записей файлов (таблиц)

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

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

10.3. Словарь данных

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

11. Состав и привилегии пользователей, распределение функций между ними Необходимо описать:

• какие категории пользователей будут взаимодействовать с системой;

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

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

• структуру и состав АРМ пользователей (в случае их наличия) с перечнем
решаемых на каждом из них задач.

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

• просмотр;

• внесение новых записей;

• корректировка отдельных полей записей;

• удаление записей;

• создание новых файлов (таблиц);

• удаление файлов (таблиц).

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

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

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

12. Требования к интерфейсу пользователя

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

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

• технические средства для ввода информации пользователем;

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

• общая характеристика экранных форм;

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

• тип отображаемой на экране информации;

• требования к представлению справочной информации .

13. Структура меню программной системы

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

14. Детальное описание программных модулей

14.1. Описание алгоритма функционирования модуля

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

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

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

• регламент работы, периодичность и продолжительность;

• режим управления запуском;

• входные данные (их структура, объемы, источники поступления);

• выходные отчеты.

14.2. Описание экранных форм, вызываемых модулем

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

• управляющее окно, содержащее меню и функциональные клавиши;

• окно для ввода данных;

• окно для ввода поисковых атрибутов;

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

• окно для вывода результатов.

Каждое экранное окно должно быть подробно описано:

• его функциональное назначение;

• кем вызывается (родительское окно);

• общая структура окна;

• описание полей;

• меню и функциональные клавиши;

• правила передвижения по элементам окна;

• описание операций, которые выполняются при перемещении по элементам
окна, по полям и записям.

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

Для каждого выходного отчета необходимо указать:

• какой функциональный модуль его создает и из какой экранной формы он
получается;

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

• какие выходные данные включаются в отчет;

• структуру документа с описанием расположения и содержания полей;

• алгоритм создания отчета;

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

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

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

• защита информации от несанкционированного доступа;

• защита информации от возможных случайных и умышленных искажений,
утраты и хищений.

17. Технические и программные средства

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

Для комплекса программных средств указываются предполагаемые для использования типы:

• операционной системы;

• системы управления базой данных;

• сетевое программное обеспечение.

18. Рекомендации по распространению программного изделия
Отмечается, где может быть эффективно использовано разрабатываемое

программное изделие.

Приложения

1. Технико-экономическое обоснование разработки.

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

3. Перечень разрабатываемой документации.

3. Руководство пользователя

3.1. Общие замечания

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

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

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

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

Целесообразно дать иллюстрации в виде экранов с описанием особенностей манипуляций на клавиатуре.

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

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

• общие сведения;

• описание применения;

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

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

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

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

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

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

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

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

3.2. Содержание разделов руководства

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

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

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

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

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

2. Описание применения

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

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

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

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

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

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

2.7. Схемы Н 1 РО . Приводится общая схема обработки данных в системе с
возможной разбивкой по режимам функционирования. Каждый блок обработки
снабжается описанием потоков входных и выходных данных.

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

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

3.1. Запуск системы . Дается пошаговое описание процедур в процессе ини
циализации процесса обработки данных в системе.

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

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

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

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

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

3.3.1. Форматы вывода . Приводятся макеты всех выходных форм и эк
ранов с объяснениями каждого раздела формы.

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

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

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

4. План приемо - сдаточных испытаний

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

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

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

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

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

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

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

Документ содержит следующие разделы:

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

— План испытаний.

— Технические требования к испытаниям и оценка результатов.

— Описание испытаний.

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

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

2. План испытаний .

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

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

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

3. Технические требования к испытаниям и оценка результатов .

3.1. Описание испытаний . Подробно описывается распределение тестов по
функциям программного изделия. Характеризуется каждый тест и описывается вся
последовательность выполнения тестов для осуществления всего комплекса прове
рок.

3.1.1. Требования .

3.1.2. Функции программного изделия .

3.1.3. Распределение тестов по функциям программного изделия .

3.1.4. Последовательность прогона тестов .

3.2. Методы и ограничения . Кроме описания тестов, определяется общая ме
тодология проведения испытаний и условия проведения испытаний, включающие
тип используемых тестовых данных, параметры потоков тестовых данных и полнота
проводимых испытаний (полные, частичные, выборочные).

3.2.1. Методология проведения испытаний .

3.2.2. Условия проведения испытаний .

3.2.3. Глубина проверок .

3.2.4. Регистрация результатов проверок .

3.2.5. Ограничения возможностей проводимых испытаний .

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

3.3.1. Критерии оценивания .

3.3.2. Преобразования тестовых данных при испытаниях .

4. Описание испытаний .

4.1. Тест ( с идентификатором ).

4.1.1. Организация выполнения теста .

4.1.2. Входные данные и команды ввода .

4.1.3. Выходная информация и возможные промежуточные сообщения .

4.1.4. Процедуры реализации теста .

4.2. Гест ( с идентификатором ). Описываются последующие тесты.

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

Приложение 2

Типовая форма титульного листа курсового проекта