М. Фаулер, К. Скотт - UML Основы, страница 6

В этом еще одно преимущество языка БМЬ; он поощряет разработчиков создавать новые методы без дублирования уже выполненной кем-то работы. Основы процесса разработки БМ( — это язык моделирования, а вовсе не метод. Язык СМ1. не содер- жит понятие процесса, который является важной частью метода. Название атой книги — «БМ».. Основы», поэтому можно было бы совершенно спокойно игнорировать сам процесс.

Тем не менее, я думаю, что методы моделирования не имеют смысла без знания того, как они могут быть использованы в процессе. Я решил рассмотреть процесс в первую очередь, чтобы вы могли представить, каким образом выполняется объектно-ориентированная разработка. Но это не попытка глубоко проникнуть в многочисленные детали этого процесса, а лишь описание его основных особенностей. Знания последних вполне достаточно для типичного использования этих методов при разработке проекта. «Трое друзей» разработали некий единый процесс, получивший название йа11опа1 УпЦ(ей Ргосеяа.

(Ранее я использовал в его названии слово ОЬ|есгогу.) Этот процесс описан в книге «трех друзей» (Джекобсон, Буч и Рамбо, 19991231). Рассматривая основы процесса, я буду пользоваться терминологией и базовыми понятиями Рационального унифицированного процесса (ВаФ(опа1 Сп(1(еб Ргосезэ). Однако я не пытаюсь дать описание самого ВОР, поскольку это выходит за рамки данной книги. Взамен приведу лишь достаточно поверхностное и неформальное описание процесса, которое согласуется с ВОР. Тем, кто заинтересуется всеми деталями Рационального унифицированного процесса, следует обратиться к 30 Глава 2.

Основы процесса разработки книге «троих друзей е, посвященной процессу (23], или к обзору Крухтена (Кгцс)треп), 1999 (27). Хотя Рациональный унифицированный процесс содержит детальное описание того, какого рода модели следует разрабатывать на различных фазах процесса, я не буду углубляться в такие детали. Также не будут описываться задачи, ресурсы и роли. Моя терминология беднее, чем терминология К11Р; это та цена, которую приходится платить за поверхностное описание. Какой бы процесс ни рассматривался, не забывайте, что с языком 1)М1. можно использовать любой процесс. Язык 1)М1.

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

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

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

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

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

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

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

В атом случае пропустите непонятное место и вернитесь к нему позже. 32 Глава 2. Основы процесса разработки Начало Начальная фаза может принимать множество различных форм. Для некоторых проектов это может быть беседа за чашкой кофе: «Давайте рассмотрим размещение каталога наших услуг в Интернете». Для более крупных проектов начальная фаза может превратиться во всестороннее изучение всех вариантов реализации проекта, которое займет месяцы.

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

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

Например, можно сказать следующее: Мы собираемся создать систему следующего поколения для заказчиков компании Итаттз ба!от йсасу Еотрапу и намерены использовать обьектно-ориентированную технологию для построения более гибкой системьь которая будет в большей степени ориентирована на пользователеи, в чоопноопи токую, которая будет поддерживать ик консолидированные счета. Вероятнее всего, ваше документальное описание требований будет более объемным, чем это, но в действительности оно не будет намного более содержательным.

В этот момент желательно попытаться лучше понять суть проблемы: ° Что вы на самом деле собираетесь создать2 Как вы собираетесь это сделать? Решая, какие вопросы рассматривать во время этой фазы, следует исходить, главным образом, из тех рисков, которые оказывают влияние на ваш проект. Что может привести к провалу проекта2 Чем больше риск, тем большее внимание ему следует уделить.

зз Исследование Исходя из моего опыта, риски полезно классифицировать на четыре категории: 1. Риски, связанные с требованиями. Каковы требования к системеу Большая опасность заключается в том, что вы построите совсем не ту систему, которая будет выполнять вовсе не то, что нужно пользователям. 2.

Технологические риски. С какими технологическими риеками вам придется столкнуться? Действительно ли позволяет выбранная вами технология реализовать ваш проект7 Каким образом следует интегрировать различные части проекта7 3. Риски, связанные с квалификацией персонала. Сможете ли вы подобрать штат сотрудников с необходимым опытом и квалификацией7 4. Политические риски. Существуют ли политические силы, которые могут оказаться на вашем пути и серьезно повлиять на выполнение вашего проекта? В вашем случае рисков может быть и больше.

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