3556 ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

Во втором разделе описаны три технологии индустриального проектирования корпоративных ИС: объектно-ориентированное проектирование, прототипное проектирование (RAD-технология) и типовое параметрически-ориентированное проектирование систем. Первые две технологии реализуются современными CASE-средствами. Типовое проектирование, по сути дела, представляет собой систематический набор подходов к конфигурации систем из готовых типовых решений.

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

Некоторые вопросы проектирования программного обеспечения, такие как документирование ПО, оценивание затрат на жизненный цикл, коллективная разработка программного продукта, оценка качества программного обеспечения рассмотрены в ранее изданном пособии [7]. Современные стандарты на документирование программных средств изложены в [8].

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

Все наиболее важные темы проектирования информационных систем и технологии разработки программного обеспечения, включая COM, CORBA, ADO, изложены в электронном учебнике авторов данного пособия «Проектирование информационных систем (ПрИС)».

 

1. Технологический цикл разработки программных средств

1.1. Программное обеспечение как промышленный продукт

Дисциплина «Технология разработки программного обеспечения» (ТРПО) предусматривает изучение вопросов разработки индустриальных программных средств, которые можно квалифицировать как программный продукт (ПП) производственно-технического назначения. Это программы на носителях данных с технической документацией, разработанные в соответствии с действующими стандартами, прошедшие приемо-сдаточные испытания и готовые к эксплуатации без участия разработчика. ГОСТ 19.004-80 ЕСПД [6] устанавливает термин «программное изделие» для обозначения программы на носителе данных, являющейся продуктом промышленного производства.

1.2. Технология разработки ПО

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

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

1.3. Требования к современным технологиям разработки ПО

  1. ТРПО должна обеспечивать отторжимость ПО от разработчика. Это необходимо для грамотного сопровождения, модификации и воспроизводства ПП в других условиях эксплуатации.
  2. ТРПО и средства ее поддержки должны обеспечивать целенаправленную работу прежде всего коллектива программистов, а не отдельных исполнителей. Основные части любой современной технологии: сетевое планирование, система формализованных поручений и эффективный контроль за их исполнением.
  3. ТРПО должна обеспечивать автоматизацию всех этапов работы коллектива программистов.
  4. ТРПО не должна быть связана с языком программирования, т.к. не он является определяющим звеном ТРПО.
  5. ТРПО должна быть простой в освоении, с автоматизированными средствами подсказки и обучения.
  6. ТРПО должна иметь средства фиксации всех действий в процессе изготовления программного продукта (автоматизированное хранение системных журналов, дневников разработки). Это необходимо для восстановления состояния процесса разработки на любом его этапе (при комплексной отладке и сопровождении ПО).
  7. ТРПО должна обеспечивать пользователю ПП доступ к документации на продукт (техническому описанию, инструкции пользователю, инструкции по эксплуатации и т.п.) на магнитных носителях. Доступ должен быть простым и автоматизированным. Работа пользователя должна обеспечиваться информационно-справочной системой.

1.4. Этапы проектирования сложных программных средств

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

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

2) программы с большой длительностью эксплуатации – создаются для регулярной обработки информации и управления; такие программы содержат от 1 до 1000000 команд, обладают свойством независимости от разработчика, возможностью модификации в процессе сопровождения и использования различными программистами, допускают тиражирование, сопровождаются документацией как промышленное изделие, являются отчуждаемыми; жизненный цикл таких программ составляет 10 – 20 лет, из них 70 – 90 % занимает время эксплуатации.

Все последующее изложение ориентировано на ПО второй группы.

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

Фаза жизненного цикла

Стадия разработки
по ГОСТ 19.102-77 ЕСПД

Состояние ПО
в конце фазы

1. Системный анализ:

а) выработка требований;

б) разработка спецификаций

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

Функциональная

архитектура

2. Проектирование:

а) проектирование архитектуры;

б) детальное проектирование

 

Эскизное проектирование

Техническое проектирование

 

 

Системная архитектура

3. Реализация (конструирование):

а) кодирование;

б) интеграция;

в) тестирование (сертификация)

Рабочее проектирование

 

 

Коды программ

Программное средство

4. Внедрение:

а) изготовление;

б) установка на ЭВМ пользователя

Внедрение

 

Программный продукт

Программное обеспечение

5. Эксплуатация

Эксплуатация

 

6. Сопровождение

Сопровождение

 

1.5. Содержание основных фаз жизненного цикла ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания. Комментарии: временные характеристики, необычные ситуации, приводящие к ошибкам и т.п.

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

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

Фаза 4. Внедрение. Полное, упорядоченное, координируемое пользователем приобщение к реальной среде новой или измененной системы. Подтверждение соответствия требованиям.

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

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

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

1.6. Взаимодействие фаз жизненного цикла ПО

 

В [3] приведены данные об относительных временных затратах на стадиях «Системный анализ» – «Проектирование» – «Реализация» (общие затраты на этих стадиях – 100 %):

«Выработка требований» – 10 %; «Разработка спецификаций» – 10 %;

«Проектирование» – 15 %; «Кодирование» – 20 %;

«Автономное тестирование» – 25 %; «Комплексное тестирование» – 20 %.

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

«Выработка требований» – 3 %; «Разработка спецификаций» – 3 %;

«Проектирование» – 5 %; «Кодирование» – 7 %;

«Автономное тестирование» – 8 %; «Комплексное тестирование» – 7 %;

«Внедрение», «Эксплуатация», «Сопровождение» – 67 %.