Практическая часть

1. Рациональная организация разработки программного обеспечения компьютерных систем

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

Это мнение во многих случаях является заблуждением, а в случае разработки программ оно является опасным заблуждением. Разумеется, разработчики программ хорошо обучены, но это слишком молодая профессия. В результате разработчикам требуется организационное руководство, которое в этой книге носит название "Процесс разработки программного обеспечения". Кроме того, поскольку процесс, который мы излагаем в этой книге, представляет собой сочетание различных до недавнего времени методологий, мы считаем, что правильно будет называть его "Унифицированным процессом". Он объединяет не только работу трех авторов, в него входят многочисленные труды отдельных людей и компаний, создававших UML, а также значительного числа основных сотрудников Rational Software Corporation. В нем успешно использован опыт сотен организаций, применявших ранние версии процесса на площадках заказчиков.

Дирижер симфонического оркестра, например, всего-то и делает во время концерта, что подает музыкантам знак к началу и задает им единый темп. Ему не нужно больше ничего делать, потому что он руководил оркестром на репетициях и подготовил исполняемую партитуру. Кроме того, каждый музыкант прекрасно знает свой инструмент и играет на самом деле независимо от других членов оркестра. Что более важно для нашей цели, каждый музыкант следует "процессу", давно предписанному ему композитором. Это музыкальный темп, который является основой "политики и процедур", управляющих исполнением музыки. В противоположность музыкантам, разработчики программного обеспечения не могут играть, не глядя на окружающих. Они взаимодействуют друг с другом и с пользователями. У них нет темпа, которому они следуют, - зато у них есть процесс.

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

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

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

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

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

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

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

• Организационные шаблоны. Пока разработчики программ не являются независимыми экспертами, как музыканты симфонического оркестра, они далеки от тех работников-автоматов, на которых Фредерик В. Тейлор (Frederick W. Taylor) строил "научное управление" сто лет назад. Создатели процесса должны адаптировать процесс к реалиям сегодняшнего дня - фактам виртуальной организации, удаленной работе по высокоскоростным линиям, присутствию как частичных владельцев (в небольших фирмах, начинающих разработки), постоянных работников, так и контрактников и удаленных субконтракторов, и постоянному недостатку разработчиков.

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