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

Введение

1_1

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

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

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

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

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

1 2

Введение

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

Язык моделирования должен включать: элементы модели - фундаментальные концепциимоделирования и их семантику; нотацию — визуальное представление элементов моделирования; руководство по использованию —правила применения элементов в рамках построения тех или иных типов моделей ПО.

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

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

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

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

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

Введение

^3

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

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

Перечисленные проблемы породили потребность в программ- но-технологических средствах специального класса — CASE-сред- ствах, реализующих CASE-технологию создания и сопровождения ПО ЭИС.Термин CASE (Computer Aided Software Engineering) имеет весьма широкое толкование. Первоначально значение термина CASE ограничивалось вопросами автоматизации разработки только лишь программного обеспечения, а в настоящее время оно приобрело новый смысл и охватывает процесс разработки сложных ЭИС в целом.

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

14

Введение

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

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

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

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

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

ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Прочитав эту главу, вы узнаете:

•Что представляет собой жизненный цикл программного обеспече-

ния (ЖЦ ПО) и какие процессы входят в его состав.

•Что такое модель ЖЦ ПО.

•Какие стадии включает в себя жизненный цикл любого ПО.

•	В чем заключаются каскадная и спиральная модели ЖЦ ПО.
•	Какие требования предъявляются к методам и технологиям проек-
	тирования ПО.

1.1.

ПОНЯТИЕ ЖИЗНЕННОГО ЦИКЛА ПО. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА

			1.1.1.
			ПОНЯТИЕ
		ЖИЗНЕННОГО ЦИКЛА ПО
Понятие жизненного цикла программного обеспечения (ЖЦ ПО)
является одним из базовых в программной инженерии.			Жизнен-
ный цикл	программного	обеспечения	о п р е д е л

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 "Information Technology -Software Life Cycle

1 IEEE Std 610.12 - 1990. IEEE Standard Glossary of Software Engineering Terminology

16

Глава 1

Processes" (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission —Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

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

Следует отметить, что в России создание ПО первоначально, в 70-е гг., регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации - серия ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно. Процессы создания автоматизированных систем (АС), в состав которых входит и ПО, регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако процессы создания ПО для современных распределенных ЭИС, функционирующих в неоднородной среде, в этих стандартах отражены недостаточно, а отдельные их положения явно устарели. В результате для каждого серьезного проекта ЭИС приходится создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПО, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

Жизненный цикл	17
В соответствии со стандартом	ISO/IEC 12207 все процессы ЖЦ
ПО разделены на три группы (рис. 1.1):
Основные процессы	Вспомогательные
	процессы
Приобретение	Документирование
	Управление
Поставка	конфигурацией
	Обеспечение
	качества
Эксплуа-	Верификация
тация

Аттестация

	Разра-	Совместная
	ботка
		оценка
		Аудит
		Сопровож-
		дение
		Разрешение
		проблем

Организационные процессы

Создание Управление инфраструктуры

Усовершенствование Обучение

Рис. 1.1. Процессы жизненного цикла программного обеспечения

18

Глава1

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

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

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

1.1.2. ОСНОВНЫЕ ПРОЦЕССЫЖЦ ПО

Процесс приобретения (acquisition process). Онсостоит издействий и задач заказчика, приобретающего ПО. Данный процесс охватывает следующие действия:

1)инициирование приобретения;

2)подготовку заявочных предложений;

3)подготовку и корректировку договора;

4)надзор за деятельностью поставщика;

5)приемку и завершение работ.

Инициирование приобретения включает следующие задачи:

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

•анализ требований к системе;

•принятие решения относительно приобретения, разработкиили усовершенствования существующего ПО;

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

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

Заявочные предложения должны содержать:

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

•перечень программных продуктов;

•условия и соглашения;

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

Жизненный цикл

19

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

Подготовка и корректировка договора включают следующие задачи:

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

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

•подготовку и заключение договора с поставщиком;

•внесение изменений (при необходимости) в договор в процессе его выполнения.

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

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

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

1)инициирование поставки;

2)подготовку ответа на заявочные предложения;

3)подготовку договора;

4)планирование;

5)выполнение и контроль;

6)проверку и оценку;

7)поставку и завершение работ.

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

Планирование включает следующие задачи:

•принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;

•разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответ-

20

Глава 1

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

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

Процесс разработки включает следующие действия:

1)подготовительную работу;

2)анализ требований к системе;

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

4)анализ требований к ПО;

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

6)детальное проектирование ПО;

7)кодирование и тестирование ПО;

8)интеграцию ПО;

9)квалификационное тестирование ПО;

10)интеграцию системы;

11)квалификационное тестирование системы;

12)установку ПО;

13)приемку ПО.

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

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

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