Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 [ 5 ] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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

UML - это язык моделирования, а вовсе не метод. Язык UML не содержит понятие процесса, который является важной частью метода.

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

Трое друзей разработали некий единый процесс, получивший название Rational Unified Process. (Ранее я использовал в его названии слово Objectory.) Этот процесс описан в книге трех друзей (Джекобсон, Буч и Рамбо, 1999 [23]).

Рассматривая основы процесса, я буду пользоваться терминологией и базовыми понятиями Рационального унифицированного процесса (Rational Unified Process). Однако я не пытаюсь дать описание самого RUP, поскольку это выходит за рамки данной книги. Взамен приведу лишь достаточно поверхностное и неформальное описание процесса, которое согласуется с RUP. Тем, кто заинтересуется всеми деталями Рационального унифицированного процесса, следует обратиться к

книге троих друзей , посвященной процессу [23], или к обзору Крух-тена (Kruchten), 1999 [27].

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

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

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

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

Общее представление о процессе

На рис. 2.1 изображено самое общее представление о процессе разработки.

Исследование

-\-\-

Построение

Внедрение

Рис. 2.1. Схема процесса разработки

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

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

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

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

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

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

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

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

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

1 2 3 4 [ 5 ] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.