Файл: Инфрам.pdf

9 8) в разработку программы вовлечено значительное количество людей
(десятки и сотни человек). Большую программу практически невозможно написать с первой попытки, с небольшими усилиями и в одиночку;
9) большая программа имеет намного большее количество ее возмож- ных пользователей по сравнению с небольшими программами, и еще больше тех лиц, деятельность которых будет так или иначе затронута ее работой и результатами.
Примерами больших программ могут служить операционные систе- мы, системы программирования, системы сетевых протоколов, библиоте- ки классов Java или C# и т.п. Строго говоря, ни одно из указанных свойств не является обязательным для того, чтобы программу можно бы- ло считать большой, но при наличии двух-трех из них достаточно уве- ренно можно утверждать, что она большая. На основании некоторых из перечисленных свойств можно сделать вывод, что большая программа или программная система чаще всего представляет собой не просто код или исполняемый файл, а включает еще и набор проектной и пользова- тельской документации.
Рост спроса на программные системы (ПС) является следствием того, что по мере удешевления, повышения надежности и увеличения объема производства компьютеров автоматизация труда человека с помощью компьютера становится все более выгодной. Эту тенденцию, отмеченную
Б. Боэмом еще в 80-е годы прошлого века и подкрепленную нашим вре- менем, иллюстрирует рис. 1.1, на котором показано расширение масшта- бов использования компьютеров и увеличение социального влияния этого использования. Надо сказать. Часто жизнь вносит свои поправки и ожи- даемые события опережают время.
Рис. 1.1. Тенденция расширения масштабов использования компьютеров
В США к 1985 году примерно 40 % работающих использовали в своей профессиональной деятельности компьютер и программные системы (ряд
1 на рис. 1.1), не обязательно зная, как эти средства функционируют [4].
По данным [16] в США в 2010 году уровень использования компьютеров составил 90%, в Европе — 70%. Однако эта тенденция усиливается, и к
2015 году около 95% работающих будут использовать компьютеры в

10 своей повседневной деятельности. При этом более половины пользовате- лей будут иметь определенные знания о работе компьютера.
Еще более глубокое воздействие компьютеры и ПС оказывают на ча- стную жизнь. С каждым днем все большая часть данных, относящихся к личной жизни, банковским счетам, коммунальным услугам, медицинско- му обслуживанию, управлению движением, воздушному сообщению, общественному питанию, производству материальных ценностей и др., а также национальной безопасности доверяется компьютерам и программ- ным системам. Поэтому все труднее становится ограничивать потенци- альную угрозу личному благосостоянию, которая возможна при исполь- зовании компьютеров в преступных целях, а также из-за наличия большо- го числа банков и баз данных, содержащих сведения о всех и обо всем, и вычислительных систем, заставляющих людей думать и действовать как машины.
В нашей стране с 1 января 2010 года все организации, обрабатываю- щие в своих информационных системах персональные данные физиче- ских лиц (сотрудников, клиентов, партнеров и т.п.), независимо от разме- ра и формы собственности должны выполнять требования, установлен- ные законом № 152-ФЗ «О персональных данных» [22]. Последние изме- нения по защите персональных данных были внесены федеральным зако- ном № 261-ФЗ от 25.07.2011. Этим законом была уточнена сфера дейст- вия Федерального закона «О персональных данных», используемые в нём основные понятия, принципы и условия обработки персональных данных.
Все возрастающее воздействие компьютеров на благосостояние чело- века предъявляет несколько важных требований к созданию программ- ных систем. Эти требования состоят в необходимости такой разработки и сопровождения ПС, которые гарантируют, что вычислительные системы должны быть: исключительно надежными; удобными в использовании; безопасными и труднодоступными для злоупотреблений; проверяемыми; оставляющими главную (решающую) роль за человеком, а не компь- ютером.
Основная доля затрат при создании таких вычислительных систем приходится на прикладное программное обеспечение (ПО) и базы данных
(БД). Производство ПО является в настоящее время крупнейшей отрас- лью мировой экономики, в которой заняты миллионы специалистов, не- посредственно производящих программный продукт или опосредованно участвующих в этом процессе.
Стоимость и качество производимого программного продукта опреде- ляется уровнем развития инженерного программирования. Важность ин- женерного программирования обусловливается двумя основными тен- денциями: программные продукты являются сложными изделиями, и их стои- мость все более возрастает;

11 программное обеспечение оказывает значительное и все возрастаю- щее воздействие на общественно благосостояние и развитие общества.
Темпы роста производства ПО в настоящее время в ряде стран выше темпов роста экономики в целом. При этом по сравнению со стоимостью аппаратуры вычислительных систем стоимость ПО продолжает расти в соответствии с предсказанными в ряде публикаций закономерностями. В настоящее время эта тенденция стала настолько ярко выраженной, что аппаратуру можно рассматривать как своего рода упаковку ПО [4], кото- рое в решающей степени определяет ценность вычислительной системы
(рис. 1.2).
Рис. 1.2. Распределение затрат на виды обеспечения компьютерных систем
Рост спроса на программные системы предъявляет существенные тре- бования к инженерному проектированию. Требования эти двоякого рода: во-первых, существенно повысить производительность труда при разра- ботке программного обеспечения, и, во-вторых, повысить эффективность сопровождения программного продукта (ПП). Последнее особенно важ- но, поскольку сопровождение требует больших затрат, чем разработка
(рис. 1.2). В частности, еще по данным 80- годов прошлого века, приве- денным Б. Боэмом [4], среднее распределение затрат по 477 системам обработки данных оказалось следующим: разработка – 43,7%, сопровож- дение – 48,8%, другие работы – 7,9%. Более свежие данные по ряду ис- точников [13] свидетельствуют о подтверждении такого распределения и в настоящее время. И это несмотря на совершенствование инструмен- тальных систем, методологии программирования и развитие CASE- средств поддержки всех этапов жизненного цикла программных систем.

12 мы с обратной связью, которые управляют или сами управляются собы- тиями физического мира и для которых ресурсы времени и памяти огра- ничены; задачи поддержания целостности информации объемом в сотни тысяч записей при параллельном доступе к ней с обновлениями и запро- сами; системы управления и контроля за реальными процессами (напри- мер, диспетчеризация воздушного или железнодорожного транспорта).
Системы подобного типа обычно имеют большое время жизни, и боль- шое количество пользователей оказывается в зависимости от их нормаль- ного функционирования. В мире промышленных программ мы также встречаем среды разработки, которые упрощают создание приложений в конкретных областях, и программы, которые имитируют определенные стороны человеческого интеллекта.
Существенная черта промышленной программы - уровень сложности: один разработчик практически не в состоянии охватить все аспекты такой системы. Грубо говоря, сложность промышленных программ превышает возможности человеческого интеллекта. Увы, но сложность, о которой мы говорим, по-видимому, присуща всем большим программных систе- мам. Говоря "присуща", мы имеем в виду, что эта сложность здесь неиз- бежна: с ней можно справиться, но избавиться от нее нельзя.
Проблемы создания программных систем (ПС) следуют из их свойств и именно из их сложности. Современные крупномасштабные проекты ПС характеризуются следующими особенностями [4, 8, 17, 19, 20]:
структурной сложностью (многоуровневой иерархической струк- турной организацией) и территориальной распределенностью;
функциональной сложностью (многоуровневой иерархией и большим количеством функций, сложными взаимосвязями между ними);
информационной сложностью, большим количеством источников и потребителей информации, разнообразными формами и форматами представления информации, сложной технологией прохождения до- кументов др.;
большим количеством внешних систем различных организаций с раз- ными форматами обмена информацией;
высокой технической сложностью, определяемой наличием совокуп- ности тесно взаимодействующих подсистем (компонентов), имеющих свои локальные задачи и цели функционирования;
сложной динамикой поведения, обусловленной высокой изменчиво- стью внешней (изменения в законодательных и нормативных актах, нестабильность экономики и политики) и внутренней среды (струк- турная реорганизация, текучесть кадров и др.);
отсутствием полных аналогов, ограничивающих возможность ис- пользования каких-либо типовых проектных решений и прикладных систем, высокой долей вновь разрабатываемых программ.
Дополнительными факторами, увеличивающими сложность разработ- ки программных систем, являются [5, 20, 26]:
1. Сложность реальной предметной области, из которой исходит за- каз на разработку. Сложность задачи и порождает сложность программ- ного продукта, Проблемы, которые пытаются решить с помощью про-

13 граммного обеспечения, часто неизбежно содержат сложные элементы, а к соответствующим программам предъявляется множество различных, порой взаимоисключающих требований. Эта внешняя сложность обычно возникает из-за "нестыковки" между пользователями системы и ее разра- ботчиками: пользователи с трудом могут объяснить в форме, понятной разработчикам, что на самом деле нужно сделать. Бывают случаи, когда пользователь лишь смутно представляет, что ему нужно от будущей про- граммной системы. Это в основном происходит не из-за ошибок с той или иной стороны; просто каждая из групп специализируется в своей области, и ей недостает знаний партнера. У пользователей и разработчиков разные взгляды на сущность проблемы, и они делают различные выводы о воз- можных путях ее решения.
2. Сложность определения требований к программным системам. Во- первых, по причине необходимости учета большого количества различ- ных факторов. Во-вторых, по причине слабого (чаще всего) знания разра- ботчиками предметной области применения ПС. В то же время специали- сты в этой предметной области, как правило, не могут сформулировать проблему в нужном для разработчика ракурсе.
3. Отсутствие удовлетворительных средств формального описания поведения дискретных систем. Популярные последнее время средства графического языка UML не решают полностью этой задачи. В процессе создания ПС часто используются языки сравнительно низкого уровня
(например, С при разработке операционных систем), что приводит к ран- ней детализации операций в процессе создания ПС и увеличивает объем описания разрабатываемых продуктов (десятки миллионов строк языка программирования в операционных системах).
4. Коллективная разработка. Вследствие больших объемов ПС раз- работка ведется достаточно большим коллективом специалистов, иногда сотни и тысячи разработчиков (достаточно напомнить проект OS/360, не говоря уже о линейки современных Windows). Обеспечивать целостность и качество проекта в этом случае трудно по причине сложности органи- зации эффективного взаимодействия специалистов в таких коллективах.
5. Необходимость увеличения степени повторяемости кодов. С це- лью увеличения производительности труда компании стремятся к созда- нию библиотек компонентов, которые можно было бы использовать в дальнейших разработках. Однако в этом случае компоненты приходится делать более универсальными, что в итоге увеличивает сложность разра- ботки. Однако не только повторяемость кодов сказывается негативно.
Стремление использовать имеющийся задел приводит к “перетягиванию” нелучшего кода в последующие разработки. Здесь можно вспомнить, как
Microsoft долго уверяла общественность о ликвидации 16-разрядного
DOS-кода (и не только его) в разработке последующих операционных систем.
6. Большая программная система – это крупное капиталовложение, и нельзя позволить выкидывать сделанное при каждом изменении внешних требований. Тем не менее, даже большие системы имеют тенденцию к эволюции в процессе их использования: следовательно, встает задача о

14 том, что часто неправильно называют сопровождением программного обеспечения. Чтобы быть более точными, введем несколько терминов [6]: под сопровождением понимается устранение ошибок; под эволюцией – внесение изменений в систему в ответ на изменив- шиеся требования к ней; под сохранением – использование всех возможных и невозможных способов для поддержания жизни в дряхлой и распадающейся на час- ти системе.
К сожалению, опыт показывает, что существенный процент затрат на разработку программных систем тратится именно на сохранение. Все вместе перечисленные факторы существенно увеличивают сложность разработки программных систем.
1.2. Кризис программирования. Инженерный подход
к разработке ПС
В начале 70-х годов прошлого века в США заговорили о кризисе в программировании. Он выражался в том, что большие программные про- екты стали выполняться с отставанием от графика или с превышением сметных расходов, разработанный программный продукт не обладал тре- буемыми функциональными возможностями, производительность его была низка, качество получаемых ПС не устраивало потребителей [4. 8].
Аналитические исследования и обзоры, выполненные в последующие годы ведущими зарубежными аналитиками, показывали не слишком об- надеживающие результаты. Так, например, результаты исследований, проведенных в 1995 году компанией Standish Group, проанализировавшей работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, показали, что только 16,2% про- ектов завершились в срок, не превысили запланированный бюджет и реа- лизовали все требуемые функции [8]. С опозданием были завершены
52,7% проектов, расходы на их разработку превысили запланированный бюджет, а требуемые функции не были реализованы в полном объеме.
Аннулированы до завершения 31,1% проектов. Для двух последних кате- горий проектов бюджет среднего проекта превышен на 89%, а срок вы- полнения на 122%. В 1998 году процентное соотношение трех перечис- ленных категорий лишь немного изменилось в лучшую сторону (26, 46 и
28 % соответственно) и в последующие годы улучшилось незначительно.
Причинами столь низких показателей, по мнению разработчиков, яв- ляются следующие: нечеткая и неполная формулировка требований к программным сис- темам; недостаточное вовлечение пользователей в работу над проектом; отсутствие необходимых ресурсов; неудовлетворительное планирование и плохое управление проектом; частые изменения требований и спецификаций; новизна и несовершенство используемой технологии; недостаточная поддержка со стороны высшего руководства;