Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие
Существует убеждение, что грамотные предприниматели должны ориентироваться на навыки и умения хорошо обученных одиночек. Профессионалы знают, что надо делать, и сделают это! В своем деле они не нуждаются в политическом и организационном руководстве.
Это мнение во многих случаях является заблуждением, а в случае разработки программ оно является опасным заблуждением. Разумеется, разработчики программ хорошо обучены, но это слишком молодая профессия. В результате разработчикам требуется организационное руководство, которое в этой книге носит название "Процесс разработки программного обеспечения". Кроме того, поскольку процесс, который мы излагаем в этой книге, представляет собой сочетание различных до недавнего времени методологий, мы считаем, что правильно будет называть его "Унифицированным процессом". Он объединяет не только работу трех авторов, в него входят многочисленные труды отдельных людей и компаний, создававших UML, а также значительного числа основных сотрудников Rational Software Corporation. В нем успешно использован опыт сотен организаций, применявших ранние версии процесса на площадках заказчиков.
Дирижер симфонического оркестра, например, всего-то и делает во время концерта, что подает музыкантам знак к началу и задает им единый темп. Ему не нужно больше ничего делать, потому что он руководил оркестром на репетициях и подготовил исполняемую партитуру. Кроме того, каждый музыкант прекрасно знает свой инструмент и играет на самом деле независимо от других членов оркестра. Что более важно для нашей цели, каждый музыкант следует "процессу", давно предписанному ему композитором. Это музыкальный темп, который является основой "политики и процедур", управляющих исполнением музыки. В противоположность музыкантам, разработчики программного обеспечения не могут играть, не глядя на окружающих. Они взаимодействуют друг с другом и с пользователями. У них нет темпа, которому они следуют, - зато у них есть процесс.
Необходимость такого процесса ощущается все сильнее, особенно в тех отраслях или организациях, где задачи, выполняемые программными системами, очень важны, - в финансах, управлении воздушным движением, обороне и системах связи. Поэтому мы считаем, что успешное ведение бизнеса или выполнение общественных миссий зависят от того, как работает поддерживающее их программное обеспечение. Программные системы становятся все сложнее и сложнее, время выхода на рынок требуется сокращать, и, соответственно, разработка все более затрудняется. По этим причинам индустрия программного обеспечения нуждается в процессе, который управлял бы разработкой, так же как оркестр нуждается в заданном композитором темпе, которому подчинено исполнение.
Что такое процесс разработки программного обеспечения?
Процесс определяет, кто, когда и что делает и как достичь определенной цели. В разработке программного обеспечения цель - разработать или улучшить существующий программный продукт. Хороший процесс предоставляет указания по эффективной разработке качественного программного продукта. Он определяет и представляет наилучшие для текущего развития отрасли способы разработки. В результате этот процесс уменьшает риск и повышает предсказуемость. Общий эффект - содействие взаимопониманию и культуре.
Нам нужен такой процесс, который управлял бы действиями всех его участников - заказчиков, пользователей, разработчиков и руководства. Старые процессы не подходят для этой цели, в данный момент нам необходим лучший в промышленности процесс. Наконец, этот процесс должен быть широко распространенным, чтобы все заинтересованные лица могли понять свои роли в обсуждаемой разработке.
Процесс разработки программного обеспечения также должен подразумевать возможность многолетнего развития. В ходе этого развития он будет постоянно адаптироваться к действительному положению дел, которое определяется доступными технологиями, утилитами, персоналом и организационными шаблонами.
- Технологии. Процесс должен строиться на основе технологий - языков программирования, операционных систем, компьютеров, пропускной способности сетей, сред разработки и т. п., - существующих во время использования процесса. Например, двадцать лет назад визуальное моделирование не было широко распространено. Оно было слишком дорогим. В настоящее время создатель процесса может только догадываться, как следовало использовать эти нарисованные от руки диаграммы. Согласно этим догадкам, качество моделирования, которое мог обеспечить инициатор процесса, было не слишком высоким.
- Утилиты. Процесс и утилиты могут разрабатываться параллельно. Утилиты и процесс неразделимы. Для того чтобы переход на новый путь был оправдан, правильно разработанный процесс должен поддерживать вложения на создание обеспечивающих его утилит.
- Персонал. Тот, кто создает процесс, должен быть в состоянии ограничить набор навыков, необходимых для работы с ним. Для работы с процессом должно хватать навыков разработчиков, имеющихся под рукой в настоящее время, или навыков, использованию которых этих разработчиков можно быстро обучить. Во многих областях сейчас можно использовать встроенные техники, например проверку модели на целостность можно производить посредством компьютерных утилит.
- Организационные шаблоны. Пока разработчики программ не являются независимыми экспертами, как музыканты симфонического оркестра, они далеки от тех работников-автоматов, на которых Фредерик В. Тейлор (Frederick W. Taylor) строил "научное управление" сто лет назад. Создатели процесса должны адаптировать процесс к реалиям сегодняшнего дня - фактам виртуальной организации, удаленной работе по высокоскоростным линиям, присутствию как частичных владельцев (в небольших фирмах, начинающих разработки), постоянных работников, так и контрактников и удаленных субконтракторов, и постоянному недостатку разработчиков.
Конструкторы процесса должны уравновесить эти четыре набора условий. Кроме того, баланс должен присутствовать не только в настоящий момент, но и в будущем. Создатель процесса должен проектировать процесс так, чтобы он был в состоянии развиваться, точно так же как разработчик программного обеспечения старается не создавать системы, которые устареют, отработав едва год, он хочет, чтобы его системы, развиваясь и совершенствуясь, существовали много лет. Для того чтобы достичь необходимого уровня стабильности и зрелости, процесс должен разрабатываться несколько лет, только после этого он достигает строгости, необходимой для коммерческой разработки, и рискованность его использования снижается до разумного уровня. Разработка нового продукта - само по себе довольно рискованное дело, даже если не добавлять к ней риск недостаточно проверенного на реальных примерах процесса. Исходя из этих соображений, процесс должен быть стабилен. Без этого баланса между технологиями, утилитами, персоналом и организацией использовать процесс будет чересчур опасно.
Зачем написана эта книга
В этой книге представлен процесс разработки программного обеспечения, который постоянно был у нас в голове, когда мы создавали Унифицированный язык моделирования. Поскольку UML представляет собой стандартный способ визуализации, описания, конструирования, документирования и пересылки артефактов программных систем, мы считаем, что этот язык может быть использован в процессе разработки от его начала и до конца. UML - это средство, а не результат. Правильный результат - это прочная, гибкая и масштабируемая программа. Для ее создания используются как процесс, так и язык. Цель нашей книги - проиллюстрировать части этого процесса. Приведенное в книге приложение, посвященное языку UML, не предполагалось делать исчерпывающим или детализированным. Детальным руководством по UML можно считать The Unified Modeling Language User Guide [10]. Исчерпывающим справочником по UML является книга The Unified Modeling Language Reference Manual [II].
Для кого предназначена эта книга
Унифицированный процесс разработки программного обеспечения может использоваться любым человеком, вовлеченным в процесс разработки программ. Однако в первую очередь он предназначен для команд, которые осуществляют деятельность жизненного цикла - определение требований, анализ, проектирование, реализацию и тестирование, - то есть работают с моделями UML. Так, например, эта книга будет полезна для аналитиков и конечных пользователей, определяющих требуемую структуру и поведение системы, разработчиков приложений, проектирующих систему, которая удовлетворяет этим требованиям, программистам, превращающим проект в исполняемый код, тестерам, проверяющим и подтверждающим структуру и поведение системы, разработчикам компонентов, создающим и каталогизирующим компоненты, менеджерам проекта и менеджерам продукта.
Эта книга содержит основу объектно-ориентированных концепций. Опыт в разработке программ и объектно-ориентированном программировании полезен для понимания материала, но не является обязательным.
Подход, принятый в книге
Важнейшее место в этой книге отведено тем видам деятельности - определению требований, анализу и проектированию, - на которые делается основной упор в UML. Именно этим видам деятельности мы обязаны тому, что, выполняя процесс, в состоянии разработать архитектуру сложных программных систем. Мы будем, однако, рассматривать весь процесс, хотя и менее детально. Он оканчивается запуском исполняемой программы. Чтобы добиться этого, проекту необходимы усилия каждого члена команды, а также поддержка заинтересованных лиц. Как вы увидите, процесс опирается на огромное разнообразие видов деятельности. Создается и отслеживается множество артефактов. Эти работы не должны протекать бесконтрольно, ими следует управлять.
Полное, подробное описание процесса жизненного цикла находится за пределами возможностей любой отдельной книги. Эта книга должна была бы содержать рекомендации по проектированию, шаблоны артефактов, показатели качества, сведения по управлению проектом, управлению конфигурацией, единицы измерения и многое-многое другое! При разработке это "многое" доступно в онлайновой документации и изменяется в соответствии с требованиями новых проектов. Мы сошлемся на Rational Unified Process, новый программный продукт, предназначенный для работы в Web, который позволяет командам разработчиков программного обеспечения делать свою работу более эффективно. (Дополнительную информацию можно получить на http://www.rational.com.) Обеспечивая весь жизненный цикл программного обеспечения, Rational Unified Process дополняет Унифицированный процесс такими видами деятельности, которые в этой книге не затрагиваются или упоминаются вскользь, - бизнес-моделирование, управление проектом и управление конфигурациями.
История Унифицированного процесса
Унифицированный процесс является устоявшимся, потому что это результат трех десятилетий разработки и практического использования. На эту разработку оказывали воздействие многие факторы. Мы не будем даже пытаться указать их все (все мы просто не знаем) и оставляем это занятие для археологов программирования. Однако мы опишем вклад в этот продукт подходов Ericsson и Rational, а также некоторых других источников.
Подход компании Ericsson
Унифицированный процесс имеет глубокие корни. Используя термин, введенный Питером Р. Друкером (Peter R. Drucker), это "инновация, основанная на знаниях". "Между появлением новых знаний и их переплавкой в новую технологию проходит продолжительное время, - учит он. - Затем следует вторая продолжительная пауза, после которой новая технология появляется на рынке в виде продуктов, процессов и услуг"[19].
Одна из причин этого длительного периода затишья состоит в том, что инновации, основанные на знаниях, основаны на соединении множества различных знаний, что требует времени. Другая причина состоит в том, что люди, у которых возникли новые идеи, должны найти время обдумать их и поделиться ими с окружающими.
Чтобы рассмотреть первые шаги по созданию Унифицированного процесса, вернемся назад, в 1967 год, и внимательно присмотримся к достижениям компании Эрикссон [31, 33, 48]. В Эрикссон система моделировалась при помощи набора связанных между собой блоков (в UML это называется "подсистема" и реализуется при помощи "компонентов"). Они собирали блоки нижнего уровня в подсистемы верхнего уровня, чтобы лучше обеспечить управляемость системы. Они выделяли блоки из предварительно определенных вариантов графика, которые сейчас называются "вариантами использования". Для каждого варианта использования определялись блоки, которые кооперировались, чтобы его реализовать. Зная, за что отвечает каждый блок, можно было создать его описание. Деятельность по проектированию давала в результате комплект статических диаграмм блоков с их интерфейсами и их группировку в подсистемы. Эти диаграммы блоков прямо соответствовали упрощенной версии классов UML или диаграмм пакетов - упрощенной в том смысле, что для связи использовались только явные ассоциации.
Первым рабочим продуктом при проектировании было описание архитектуры программы. Оно основано на понимании большинства критических требований. В нем кратко описывается каждый блок и их группировка в подсистему. Набор диаграмм блоков описывает блоки и их связь друг с другом. По связям передаются сообщения особого рода - сигналы. Все сообщения описаны в библиотеке сообщений. Описание архитектуры программы и библиотека сообщений представляют собой основные документы, которые определяют разработку; кроме того, они используются для представления системы заказчикам. В то время (1968 год) заказчики еще не привыкли рассматривать программные продукты, представляемые им в виде, похожем на технические чертежи.
Для каждого варианта использования инженеры создавали диаграмму последовательностей или диаграмму коопераций (и сейчас создаваемые на языке UML). Эти диаграммы показывали, каким образом блоки динамически обмениваются информацией друг с другом с целью реализации варианта использования. Они создавали спецификацию в форме графа состояний (включающего только состояния и переходы) и графа состояний-переходов (упрощенную версию диаграмм деятельности UML). Этот подход, основанный на проектировании из блоков и хорошо описанных интерфейсов между ними, был ключом к успеху. Теперь новая конфигурация системы могла быть создана - например для нового заказчика - простой заменой одного блока на другой, имеющий аналогичный интерфейс.
Итак, блоки не были теперь просто подсистемами и компонентами исходного кода, они компилировались в исполняемые модули, без изменений устанавливались на нужную машину с последующей проверкой, выполняют ли они все, что от них требуется. Кроме того, появлялась возможность установки любого исполняемого блока в систему во время выполнения звонков для постоянно работающих телефонных систем. Для внесения изменений в систему не требовалось ее выключать. Это похоже на смену покрышек автомашины во время ее движения.
В сущности, этот подход использовал то, что мы называем сегодня разработкой, основанной на компонентах. Создателем этого метода был Ивар Джекобсон (Ivar Jacobson). Он руководил этим развитием процесса разработки программного обеспечения в течение многих лет - до периода Objectory.
Язык спецификации и описания
В тот период важнейшим делом стало издание в 1976 году CCITT, международным органом по стандартизации в области телекоммуникаций, Языка спецификации и описания (SDL) функционального поведения телекоммуникационных систем. Этот стандарт, оказавший важное влияние на подход фирмы Эрикссон, определяет систему в виде набора связанных блоков, которые общаются друг с другом исключительно путем обмена сообщениями (названных в стандарте "сигналами"). Каждый блок владеет набором "процессов" (это термин SDL для активных классов). Процесс имеет множество экземпляров, подобно классу в терминологии объектно-ориентированного подхода. Экземпляры процесса обмениваются сообщениями. Рекомендованы диаграммы, специализации которых в UML называются диаграммами классов, диаграммами деятельности, диаграммами кооперации и диаграммами последовательностей.
Итак, SDL был специализированным стандартом объектного моделирования. Периодически обновляемый, он использовался более чем 10 000 разработчиками и поддерживался некоторыми поставщиками утилит. Изначально разработанный более 20 лет назад, он далеко опередил свое время. Однако он был разработан в те времена, когда объектное моделирование было еще не развито. SDL был вытеснен Унифицированным языком моделирования, Unified Modeling Language, который прошел стандартизацию в ноябре 1997 года.
Objectory
В 1987 году Айвар Якобсон (Ivar Jacobson) покинул Эрикссон и основал в Стокгольме компанию Objectory AB. В течение следующих восьми лет он и его сотрудники разрабатывали процесс, названный Objectory ("Objectory" - это сокращение от "Object Factory", "Фабрика объектов"). Они распространили его на другие отрасли промышленности, помимо телекоммуникаций, и на другие страны, помимо Швеции.
Хотя концепция варианта использования присутствовала еще в разработках Эрикссон, теперь у нее было имя (введенное на конференции OOPSLA в 1987 году) и разработанная техника изображения при помощи диаграмм. Идея была распространена на множество приложений. Стало яснее видно, что варианты использования управляют разработкой. На передний план вышло понимание того, что архитектура направляет разработчиков и информирует заинтересованных лиц.
Последовательные рабочие процессы были представлены в виде ряда моделей: требований, вариантов использования, анализа, проектирования, реализации и тестирования. Модель - это проекция системы. Отношения между моделями в этом ряду важны для разработчиков как путь переноса свойств от одного конца ряда моделей до другого. Фактически трассируемость и стала предпосылкой к разработке, управляемой вариантами использования. Разработчики могли трассировать варианты использования по последовательности моделей до текста программ или, если возникали проблемы, обратно.
Разработка процесса Objectory происходила в виде серии выпусков, от Objectory 1.0в 1988 году до первой онлайновой версии, Objectory 3.8, в 1995 году (обзор Objectory можно найти в [34]).
Важно отметить, что сам по себе продукт Objectory мог рассматриваться как система. Такой способ описания процесса - как системы-продукта - давал хороший способ разработки новой версии Objectory на основе предыдущей. Этот способ разработки Objectory делал ее удобнее для привязки к разработке различных продуктов и выполнения частных требований конкретной разработки. Сам процесс разработки программного продукта Objectory был сконструирован на основе этого процесса, что составляет его уникальную особенность.
Опыт разработки Objectory также привел к прояснению того, как работает инженер и как в основном работает бизнес. Эти же принципы были приложены к книге, их описывающей и выпущенной в 1995 году [39].
Подход компании Rational
Rational Software Corporation приобрела Objectory AB во время спада 1995 года, и задача унификации базовых принципов, лежащих в основе существующих способов разработки программного обеспечения, опять приобрела актуальность. Rational создала несколько способов разработки программного обеспечения, многие из которых были совместимы с включенной в их число Objectory.
Так, например, "в 1981 году Rational начала производить интерактивную среду, которая повышала продуктивность разработки больших программных систем", писали Джеймс Е. Арчер мл. (James E. Archer, Jr.) и Майкл Т. Девлин (Michael Т. Devlin) в 1986 году [З]. "В этих разработках очень важны были объектно-ориентированное проектирование, абстракции, скрытие информации, многократное использование и создание прототипов", - продолжают они.
Разработки Rational с 1981 года детально описаны в книгах, докладах и внутренних документах, но, вероятно, двумя наиболее важными добавками к процессу были упор на архитектуру и итеративную разработку. Так, в 1990 году Майкл Девлин (Mike Devlin) написал концептуальную статью о направляемом архитектурой итеративном процессе разработки. Филипп Крухтен (Philippe Kruchten), заведовавший в Rational Архитектурной практикой, стал автором статей по итерациям и архитектуре.
Мы цитировали одну из них, статью об изображении архитектуры в виде четырех представлений: логическом представлении, представлении процесса, физическом представлении и представлении разработки, и дополнительном представлении, иллюстрирующем первые четыре представления при помощи вариантов использования или сценариев [52]. Идея о создании набора представлений вместо попыток впихнуть их все в один тип диаграмм была подсказана ему опытом работы в больших проектах. Множественные представления, дающие возможность взглянуть на систему под определенным углом, помогают заинтересованным лицам и разработчикам понять, какую цель они преследуют.
Кое-кто воспринимает итеративную разработку как нечто анархическое или беспорядочное. Подход четырех фаз (анализ и планирование требований, проектирование, построение и внедрение) приводит к лучшей структуре и контролю прогресса в ходе итераций. Фазы привносят в итерации порядок. Детальное планирование фаз и порядка итераций внутри них было совместной разработкой Уолкера Ройса (Walker Royce) и Рича Рейтмана (Rich Reitman), при постоянном участии Гради Буча (Grady Booch) и Филиппа Крухтена (Philippe Kruchten).
Буч участвовал во всем этом с самого начала существования Rational, а в 1996 году он сформулировал два "основных принципа", касающихся архитектуры и итераций:
- "Управляемая архитектурой разработка обычно является наилучшим способом создания очень сложных программных проектов".
- "Чтобы быть успешным, объектно-ориентированный проект должен применять инкрементный и итеративный процесс" [9].
Rational Objectory Process: 1995-1997
К моменту слияния Objectory 3.8 показал, как можно, подобно продукту, разработать и промоделировать процесс разработки программного обеспечения. Была разработана оригинальная архитектура процесса разработки программ. Был определен набор моделей, в которые записывается результат процесса. Были детально проработаны такие части процесса, как моделирование вариантов использования, анализ и проектирование. Однако другие части - управление требованиями, не входящими в варианты использования, реализация и тестирование - не имели столь детальной проработки. Кроме того, в процессе содержались только наметки информации об управлении проектом, управлении конфигурациями, развертывании и создании среды разработки (обеспечении утилитами и процессами).
Теперь к Objectory были добавлены опыт и практика Rational. Результатом стал Rational Objectory Process 4.1. В частности, добавились фазы в сочетании с управляемым итеративным подходом. Архитектура была выделена явно, в виде описания архитектуры - "катехизиса" организаций, занимающихся разработкой программ. Было разработано точное определение архитектуры. Архитектура стала восприниматься как существенная часть организации системы. Архитектура изображалась в виде набора архитектурных представлений моделей. Итеративная разработка из относительно общей концепции превратилась в управляемый рисками подход, при котором архитектура разрабатывается в первую очередь.
В это время UML находился в разработке и использовался в качестве языка моделирования для Rational Objectory Process (ROP). Первыми разработчиками UML были авторы этой книги. Команда, разрабатывавшая процесс, во главе с Филиппом Крухтеном (Philippe Kruchten), устранила некоторые из слабых мест ROP путем усиления управления проектом, например, на основе работ Ройса (Royce)[59].
Унифицированный язык моделирования
Необходимость в унифицированном и согласованном визуальном языке для точного выражения результатов довольно многочисленных объектно-ориентированных методологий, появившихся с начала 90-х годов XX века, уже некоторое время была очевидной.
В течение этого времени Гради Буч (Grady Booch), например, стал автором "метода Буча" [8]. Джеймс Рамбо (James Rumbaugh) был основным разработчиком Центра исследований и разработок Дженерал Электрик по ОМТ (Технологии объектного моделирования) [60]. Когда в октябре 1994 года они пришли в Rational, то при участии многих заказчиков Rational начали работу по унификации своих методов. Они выпустили версию 0.8 Унифицированного метода в октябре 1995 года, примерно в то же время, когда Ивар Джекобсон (Ivar Jacobson) пришел в Rational.
Эти три человека, работая совместно, выпустили версию 0.9 Унифицированного языка моделирования. При создании этой версии основные усилия были направлены на ассимиляцию работ других методологов и компаний, включая IBM, HP и Microsoft, каждая из которых способствовала созданию стандарта. В ноябре 1997 года, после прохождения процедуры стандартизации, Унифицированный язык моделирования в версии 1.1 был провозглашен стандартом Группы управления объектами. Как все это было, можно узнать в User Guide [10] и Reference Manual [II].
UML использовался во всех моделях Objectory Process.
Rational Unified Process
В ходе этих работ Rational присоединяла другие компании, производящие утилиты для разработки программ, или сливалась с ними. Каждая из них добавляла свой опыт в области процессов в копилку, расширяя Rational Objectory Process:
- Requisite Inc. вложила свой опыт в управлении требованиями.
- SQA Inc. разработала процесс тестирования для работ по тестированию продуктов, который был добавлен к немалому опыту Rational в этой области.
- Pure-Atria добавила к опыту Rational в управлении конфигурациями свой.
- Performance Awareness добавила тестирование производительности и загрузки.
- Vigortech привнесла экспертизу структуры данных.
К процессу также были добавлены основанные на [39] новые рабочие процессы для бизнес-моделирования, используемые для порождения требований к бизнес-процессам, которые должны обслуживать программное обеспечение. Также в него вошло проектирование пользовательских интерфейсов на основе вариантов использования (базировавшееся на работах Objectory АВ).
К середине 1998 года Rational Objectory Process превратился в полномасштабный процесс, способный поддерживать разработку программ в течение всего жизненного цикла. В ходе этого превращения он вобрал в себя большое количество технологий как привнесенных тремя авторами этой книги, так и почерпнутых Rational и UML из других источников. В июне Rational выпустила новую версию продукта, Rational Unified Process 5.0 [53]. Многие элементы этого внутрифирменного процесса были описаны в данной книге, и после ее выхода информация о нем стала общедоступной.
Изменение названия отражает тот факт, что произошла унификация процесса по многим параметрам: унификация подходов к разработке, использование Унифицированного языка моделирования, унификация работ многих методологов - не только в Rational, но и на сотнях площадок заказчиков, которые много лет использовали этот процесс.
Начало
Краткое содержание
Полное содержание
Заказать книгу в магазине "Мистраль"
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
