Разработка программного обеспечения автоматизированных информационных систем

Далее описаны основные разделы, и содержание проектной части.

 

1. Понятие автоматизированной информационной системы

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

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

Согласно ГОСТ 34.003-90:

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

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

Кроме АИС широкое распространение также получили автоматизированные системы управления (АСУ), которым присущи многие функции информационной системы, но кроме них еще и функции управления различными объектами и процессами.

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

Основной целью создания АИС является удовлетворение информационных потребностей пользователей путем предоставления необходимой им информации на основе хранимых данных.

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

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

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

 

2. Проектирование модели системы

При проектировании АИС применяют структурный (функционально-модульный) и объектно-ориентированный подходы.

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

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

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

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

Проектирование функциональной модели чаще всего осуществляется при помощи CASE – средства BPWin, которое поддерживает методологии IDEFO, DFD и IDEF3.

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

Наиболее удобным языком моделирования бизнес – процессов является методология (нотация) IDEF0, разработанная в 1981 году Дугласом Россом.

Язык моделирования бизнес - процессов считается следующим этапом развития хорошо известного графического языка описания функциональных систем SADT - Structured Analysis and Design Teqnique. Позднее подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0.

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

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

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

– "Управление" (Control);

– "Вход" (Input);

– "Выход" (Output);

– "Механизм" (Mechanism).

Рисунок 1 – Функциональный блок

 

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

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

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

В IDEF0 различают пять типов стрелок.

Вход (Input) – это материалы или информация, которые используются или преобразуются работой для получения результата (выходного потока). Например, чтобы показать обработку данных блоком, целесообразно на входе указать "Документ", а на выходе – "Заполненный документ". Однако не может быть входом блока "Прием экзамена" стрелка "Студент", а выходом – стрелка "Экзаменационная ведомость", т. к. студент не перерабатывается в ведомость. В данном примере в качестве входного потока можно использовать входную стрелку "Информация по аттестации студента".

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

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

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

Механизм (Mechanism)– это ресурсы, которые выполняют работу (персонал, станки, устройства, АСУ, АИС или АРМ другого назначения). Стрелка механизма рисуется как стрелка, входящая в нижнюю грань работы.

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

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

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

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

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

– контекстная диаграмма;

– диаграмма декомпозиции;

– диаграмма дерева узлов;

– диаграмма "только для экспозиции".

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

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

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

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

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

Диаграммы потоков данных (DFD, Data Flow diagramming) используются для описания процессов документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой процессов. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.

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

– потоки данных;

– процессы (работы) преобразования входных потоков данных в выходные;

– внешние сущности;

– накопители данных (хранилища).

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

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

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

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

Кроме основных элементов, в состав модели DFD входят также словари данных и миниспецификации.

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

Методология IDEF3 (WorkFlow diagramming) является стандартом документирования происходящих технологических процессов и предоставляет собой инструментарий для наглядного исследования и моделирования их сценариев(Scenario).

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

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

 

3. Разработка базы данных системы

Разработка базы данных (БД) системы включает два этапа:

1. построение модели данных системы;

2. реализация БД системы с использованием конкретной СУБД.

Для построения модели данных используется мощный и удобный инструмент – ERwin.

CASE – средство ERwin является одним из самых популярных продуктов данного класса благодаря поддержке большого количества платформ, простоте интерфейса и поддержке специфических особенностей организации физической памяти наиболее популярных серверных СУБД. Данный инструмент поддерживает более 20 типов СУБД.

CASE – средство Erwin имеет два уровня представления модели – логический (logical) и физический (physical).

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

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

4. Реализация системы

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

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

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

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

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

 

5. Программная документация

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

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

2. описание программы;

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

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

Программная документация на разработанную систему должна соответствовать требованиям соответствующих стандартов ЕСПД.

 

6. Содержание проектной части дипломного проекта

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

– разделы по описанию результатов проектирования;

– разделы по реализации программного обеспечения;

– приложения.

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

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

2. функциональное проектирование АИС;

3. разработка структуры базы данных АИС;

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

5. описание логической структуры приложения;

6. описание программы;

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

8. результаты испытаний;

9. описание применения.

 

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

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

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

– требования к программе;

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

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

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

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

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

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

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

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

Раздел «Функциональное проектирование АИС» должен содержать описание средства проектирования и созданной функциональной модели системы.

Проектирование информационной системы должно осуществляться с использованием структурного подхода с помощью CASE-технологий, например, Erwin 4.1 или CA ERWin Process Modeler 7.3 на основе анализа экономико-информационной среды предметной области.

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

Данный раздел должен включать следующие подразделы:

– описание CASE-средства BPwin;

– описание функциональной модели системы.

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

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

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

Данный раздел должен включать следующие подразделы:

– описание CASE-средства ERWin;

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

– разработка структуры связей;

– нормализация отношений модели базы данных системы;

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

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

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

Раздел «Описание программы» должен содержать описание:

– общих сведений, где приводится обозначение и наименование программы, программное обеспечение, необходимое для функционирования программы, СУБД, языки программирования, на которых она реализована;

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

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

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

Текст программы и SQL – запросы приводятся в соответствующих приложениях.

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

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

Вторая глава, представленная только в схемах без их описания, к рассмотрению не принимается!