Основные особенности проектов

СОВРЕМЕННЫХ СИСТЕМ ПО

 

Индустрия ПО начала зарождаться в середине 50-х годов XIX в., однако почти до конца 60-х ей не уделялось серьезного внимания, поскольку ее доля в компьютерном бизнесе была слишком мала. В 1970 г. годовой оборот всех фирм-разработчиков ПО в США не превышал 1/2 млрд долл. - около 3,7% всего оборота компьютерного бизнеса. Серьезный рост начался в 70-х годах XX в., начиная с принятого фирмой IBM в 1969 г. решения о развязывании цен (раздельном назначении цен на аппаратуру, ПО и услуги), и продолжился до конца декады и появления персонального компьютера. К1979 г. годовой объем продаж фирм-разработчиков ПО в США составлял около $2 млрд. В 80-х годах рост составлял 20% в год и более, таким образом, годовые доходы фирм выросли до $10 млрд. к 1982 г. и $25 млрд. к 1985 г. Сегодня общий объем продаж ПО превышает $100 млрд. Производство ПО сегодня — крупнейшая отрасль мировой экономики, в которой занято около трех миллионов специалистов, называющих себя программистами, разработчиками ПО и т.п. Еще несколько миллионов человек занимают рабочие места, напрямую зависящие от благополучия корпоративных информационных подразделений либо от производителей ПО, таких, как корпорации Microsoft или IBM.

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

Чтобы понять принципиальные отличия сложного ПО от обычной программы, рассмотрим рис. В.1[1].

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

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

Рис. В.1. Отличие комплексного программного продукта от программы

 

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

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

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

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

В 1975 г. Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Современные крупномасштабные проекты программных систем характеризуются, как правило, особенностями, представленными на рис. В. 2.

Характеристики объекта внедрения:

· структурная сложность (многоуровневая иерархическая структура организации) и территориальная распределенность;

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

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

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

Рис. В.2. Особенности современных крупномасштабных проектов программных систем

 

Технические характеристики проектов создания ПО:

· различная степень унифицированности проектных решений в рамках одного проекта;

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

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

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

· большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);

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

Организационные характеристики проектов создания ПО:

· различные формы организации и управления проектом: централизованно управляемая разработка тиражируемого ПО, экспериментальные пилотные проекты, инициативные разработки, проекты с участием как собственных разработчиков, так и сторонних компаний на контрактной основе;

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

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

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

 

ОСНОВНЫЕ ПРОБЛЕМЫ

СОВРЕМЕННЫХ ПРОЕКТОВ ПО

В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в последние годы ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Например, результаты исследований, выполненных в 1995 г. компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, выглядели следующим образом:

· только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

· 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

· 31,1% проектов были аннулированы до завершения;

· для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

В 1998 г. процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

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

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

· нечеткая и неполная формулировка требований к ПО;

· недостаточное вовлечение пользователей в работу над проектом;

· отсутствие необходимых ресурсов;

· неудовлетворительное планирование и отсутствие грамотного управления проектом;

· частое изменение требований и спецификаций;

· новизна и несовершенство используемой технологии;

· недостаточная поддержка со стороны высшего руководства;

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

В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что множество проектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Йордона[2], одного из ведущих мировых специалистов в области ПО, утвердилось название «death march», буквально - «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50%. По отношению к проектам создания ПО это означает наличие одного или более из следующих ограничений:

· план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, требующий в нормальных условиях 12 календарных месяцев, приходится выполнять за 6 или менее месяцев. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной;

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

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

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

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

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

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

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

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

1. Граница между проектированием и строительством всегда четко обозначена чертежом. Проектирование включает в себя все операции, необходимые для создания чертежа, а строительство охватывает все операции, необходимые для создания продуктов по этому чертежу. В идеальном случае чертеж должен определять создаваемый продукт во всех подробностях, что, конечно же, бывает очень редко. Тем не менее, целью чертежа является настолько подробное описание конструируемого продукта, насколько это возможно. Описывает ли проект архитектуры программной системы создаваемый продукт «во всех подробностях»? — Нет. Проект архитектуры предназначен для описания существенных, но, безусловно, не всех подробностей программной системы. Поэтому очевидно, что проект архитектуры не является чертежом. Все подробности программной системы описываются только кодом на языке высокого уровня, который, таким образом, является чертежом программы. А поскольку все операции, ведущие к созданию чертежа, являются проектированием, то и вся разработка ПО должна считаться проектированием.

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

Разработчики не строят ПО - они его проектируют. Конечный результат проектирования — код на языке высокого уровня — является чертежом ПО. Компилятор и компоновщик механически строят программный продукт — двоичный исполняемый файл— по этому спроектированному коду. Проект архитектуры программной системы наиболее близко соответствует картонным моделям или эскизам проекта, используемым в некоторых инженерных дисциплинах. Чтобы понять, почему разработчики ПО до сих пор не увидели и не нашли основных принципов, представим себе мир, в котором создание небоскреба не требует ничего, кроме подробного чертежа. Имея чертеж, архитектор мог бы одним нажатием кнопки построить небоскреб — мгновенно и практически без затрат. Затем архитектор мог бы проверить небоскреб и сравнить его с техническими требованиями. Если бы он разрушился или не смог пройти проверку, архитектор мог бы его снести и убрать обломки— мгновенно и опять же без затрат. Стал бы этот архитектор тратить много времени на формальную проверку согласованности проекта с физическими законами? Или хотя бы пытаться исследовать и понять эти законы? — Вряд ли. Он, вероятно, смог бы получить результаты быстрее путем многократного строительства, проверки и сноса небоскреба, каждый раз внося исправления в чертеж. В мире, где строительство и разрушение бесплатны, выбирается метод проб и ошибок, а фундаментальные исследования остаются на будущее.

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

Метод проб и ошибок завел достаточно далеко. Но рост сложности современных программных систем подводит нас к жесткому пределу. За пределами определенного уровня сложности создание качественных архитектур методом проб и ошибок становится невозможным.

 

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

 

Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» (software engineering ). Впервые термин software engineering был использован как тема исторической конференции Научного комитета NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии, тогда же появилось первое издание, посвященное программной инженерии, — IEEE Transactions on Software Engineering. Программная инженерия определяется, с одной стороны, как совокупность инженерных методов и средств создания ПО а, с другой стороны, как дисциплина, изучающая применение строгого систематического количественного (т.е инженерного) подхода к разработке, эксплуатации и сопровождению ПО.

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

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

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

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

В то же время попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области — неспособность эффективного управления проектами создания ПО. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания ПО, в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если для управления проектами и внедрения технологий не создается необходимой инфраструктуры и не обеспечивается техническая поддержка, то на выполнение проектов затрачивается существенно больше времени и ресурсов по отношению к планируемым (да и само планирование ресурсов выполняется «потолочным» методом»). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Успех, который держится исключительно на способностях отдельных организаторов «вытаскивать» проекты из прорывов, не дает гарантии устойчивой производительности и качества при создании ПО. Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью СММ (Capability Maturity Model) Института программной инженерии (Software Engineering Institute, SEI), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации. Процессы выстраиваются таким образом, чтобы обеспечить реальные сроки создания ПО.

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

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

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

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

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

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

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

Под сопровождением в общем случае понимается внесение изменений в эксплуатируемый программный продукт в целях исправления обнаруженных ошибок (корректирующее сопровождение), повышения производительности и улучшения эксплуатаци­онных характеристик системы (совершенствующее сопровождение), а также адаптации к изменившейся или изменяющейся среде (адаптирующее сопровождение). При этом более 50% общего объема работ по сопровождению приходится на совершенствующее сопровождение. В общих затратах различных организаций и предприятий на ПО доля затрат на сопровождение составляет от 60% до 80% (эта доля является максимальной для крупных государственных учреждений и частных компаний), и величина этих затрат продолжает расти. Негативными последствиями такого роста являются: 1) неудовлетворенность пользователей из-за большого времени, затрачиваемого на внесение изменений в ПО; 2) снижение качества ПО и 3) сокращение объема новых разработок в будущем, поскольку все большее количество разработчиков вынуждено переключаться на сопровождение. Так, по оценкам компании Hewlett-Packard, в 1994 г. от 60% до 80% ее разработчиков были заняты сопровождением ПО, а в отчетах федеральных служб США ранее отмечалось, что на сопровождение уходит от 50% до 80% рабочего времени программистов. Перечисленные тенденции отражены на рис. В.З.

 

Рис. В.З. Тенденции изменения соотношения стоимости аппаратуры и ПО

 

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

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

По данным SEI, в последние годы до 80% всего эксплуатируемого ПО разрабатывалось вообще без использования какой-либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок). Одна из причин — упомянутое выше стремление сэкономить на стадии разработки, не затрачивая времени и средств на внедрение технологического процесса создания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам, более $100 тыс. и около трех лет на внедрение развитой технологии, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина — в «тяжести» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:

· необходимость документировать каждое действие разработчиков;

· множество рабочих продуктов (в первую очередь — документов), создаваемых в бюрократической атмосфере;

· отсутствие гибкости;

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

Для того чтобы проиллюстрировать насколько «тяжелыми» могут быть формальные процессы, эксперт в области использования метрик Каперс Джонс подсчитал, что процесс разработки ПО по стандарту DOD-2167A Министерства обороны США требует 400 слов в документации на английском языке для каждой строки исходного кода. Так, если создается среднее приложение размером 50 000 строк исходного кода, потребуется наличие армии технических специалистов для создания 20 миллионов слов документации с описанием того, что делает код, как он функционирует и почему это происходит именно так.

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

 

СОВРЕМЕННЫЕ ТЕНДЕНЦИИ

В ПРОГРАММНОЙ ИНЖЕНЕРИИ

(ПРИНЦИПЫ «БЫСТРОЙ РАЗРАБОТКИ ПО»)

 

В начале 2001 г. ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и др.) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliance's Manifesto) и заключающихся в следующем[3]:

· индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

· работающее ПО ценится выше всеобъемлющей документации;

· сотрудничество с заказчиками ценится выше формальных договоров;

· реагирование на изменения ценится выше строгого следования плану.

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

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

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

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

· когда она выполняет задачи, невыполнимые вручную. Инструменты измерения и анализа собирают данные, которые иначе собрать было бы невозможно. Программисты говорят о них, как об основных инструментах;

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

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

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

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

· G — дефекты вызывают потерю удобства;

· D - дефекты вызывают потерю возместимых средств (материальных или финансовых);

· Е — дефекты вызывают потерю невозместимых средств;

· L — дефекты создают угрозу человеческой жизни. Масштаб определяется количеством разработчиков, участвующих в проекте:

· от 1 до 6 человек — малый масштаб;

· от 6 до 20 человек - средний масштаб;

· свыше 20 человек — большой масштаб.

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

· интерактивное общение лицом к лицу — это самый дешевый и быстрый способ обмена информацией;

· избыточная «тяжесть» технологии стоит дорого;

· более многочисленные команды требуют более «тяжелых» и формальных технологий;

· большая формальность подходит для проектов с большей критичностью;

· возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;

· дисциплина, умение и понимание противостоят процессу, формальности и документированию;

· потеря эффективности в некритических видах деятельности вполне допустима.

Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является «Экстремальное программирование» (Extreme Programming — ХР[4]). Далее приве­дено краткое изложение этого метода.

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

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

3. Единицей собираемых требований к ПО является «пользовательская история» (user story), описывающая с точки зрения пользователя функциональность, которая может быть разработана за одну итерацию. Заказчики записывают истории на простых индексных карточках. Заказчики и программисты договариваются о планах на следующую итерацию таким образом:

· программисты оценивают время для завершения работы с каждой карточкой;

· заказчики расставляют приоритеты, изменяют и пересматривают их при необходимости, чтобы самые ценные истории с наибольшей вероятностью были выполнены в выделенный период времени.

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

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

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

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

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

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

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

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

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

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

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

 

! Следует запомнить

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

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

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

4. Неотъемлемыми свойствами ПО являются сложность, согласованность, изменяемость и незримость.

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

 

Основные понятия

Информационная система, программное обеспечение, проект, проектирование, программная инженерия, «быстрая разработка ПО».

 

? Вопросы для самоконтроля

1. В чем состоит цель проектирования ПО?

2. Каковы основные особенности и проблемы современных крупномасштабных проектов программных систем?

3. В чем заключаются основные причины неудач проектов и каким представляется выход из положения?

4. Что означает «быстрая разработка ПО»?

 

ГЛАВА 1

ЖИЗНЕННЫЙ ЦИКЛ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

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

· Что представляет собой жизненный цикл программного обеспечения (ЖЦ ПО) и какие процессы входят в его состав.

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

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

· В чем заключаются каскадная и итерационная модели ЖЦ ПО.

· Какие требования предъявляются к уровню зрелости организаций — разработчиков ПО.

 

1.1.

НОРМАТИВНО-МЕТОДИЧЕСКОЕ

ОБЕСПЕЧЕНИЕ СОЗДАНИЯ ПО

 

Разработка больших проектов, связанная с работой коллективов размером в несколько десятков и даже сотен человек из нескольких организаций, немыслима без совокупности нормативно-методических документов, регламентирующих различные аспекты процессов деятельности разработчиков[5]. Комплекс таких документов называют нормативно-методическим обеспечением (НМО). Эти документы регламентируют:

· порядок разработки, внедрения и сопровождения ПО;

· общие требования к составу ПО и связям между его компонентами, а также к его качеству;

· виды, состав и содержание проектной и программной документации.

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

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

· виду регламентации (стандарт, руководящий документ, положение, инструкция и т.п.);

· статусу регламентирующего документа (международный, отраслевой, предприятия);

· области действия документа (заказчик, подрядчик, проект);

· объекту регламентации или методического обеспечения.

Нормативной базой НМО являются международные и отечественные стандарты в области информационных технологий и прежде всего:

· международные стандарты ISO/IEC (ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике);

· стандарты Российской Федерации ГОСТ Р;

· стандарты организации-заказчика.

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

 

1.2.