книги / Надежность программного обеспечения систем обработки данных

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

		I = 1
где /' —		время повторного выполнения операций (час),
с’	—	стоимостные затраты на единицу времени (час)
	—	повторяемой операции,
k		количество повторяемых выполнений операций

Тогда общая формула определения стоимостных затрат будет иметь вид:

п т		h
2 обш =	‘ ч ' с ц +	• с ]
<- I / - I	/ -	I

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

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

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

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

81

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

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

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

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

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

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

8 7

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

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

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

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

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

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

В общем виде цикл жизни ПО можно считать со­ стоящим из трех этапов: определения, реализации и со­ провождения. Содержание этих этапов приближенно со­ ответствует определенным ГОСТом стадиям создания ПО и предусмотренным в них документам.

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

83'

Этапы

Рис 4 I Цикл жизни ПО

ни завершения одного этапа и перехода к следующему этапу.

Рассмотрим содержание укрупненных этапов. Определение программного средства. Процесс создав

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

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

84

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

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

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

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

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

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

85

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

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

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

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

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

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

<6

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

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

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

Трудом* ресурсы (чел.тод1

Рнс. 4 2 Распределение трудовых ресурсов по фазам

цикла жизни ПО:

1т— время завершения разработки.

(	кривая трудозатрат на овределеине требований к системе в делом
г	— кривая трудозатрат нв овреаедеяке требований к ПО
”	— краавя труаозвтрят на вроеитированне. кодирование и отладку
;	кривая трудозатрат на тестирование ПО.
*	кривая трудозатрат ка ввод ПО в эксплуатацию

87

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

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

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

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

4.3 ФАКТОРЫ, ОПРЕДЕЛЯЮЩИЕ ЗАТРАТЫ НА РАЗРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

88

Рнс. 4 3. Факторы, определяющие стоимость разработки ПО

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

Факторы, определяющие затраты на разработку ПО, можно условно разделить на три группы (рис. 4.3).

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

В результате исследования зависимости стоимостных затрат от объема ПО, проведенного фирмой TRW [10], была обнаружена положительная корреляционная зави­ симость с коэффициентом г = 0,89.

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

89

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

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

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

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

В зависимости от назначения разрабатываемого ПО затраты на разработку достаточно широко варьируют Так, разработка операционной системы и ее компонентов обходится в 2—2,5 раза дороже разработки прикладных программ или программ-утилит в расчете на одну исход­ ную команду [6].

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

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

Факторы, определяемые как размеры, принятая струк­ тура базы данных признаются предельно важными для проектов, ориентированных на обработку больших мас-

90