М. Фаулер, К. Скотт - UML. Основы - 2002 (1158629), страница 6
Текст из файла (страница 6)
Передача разработанного программного обеспечения в эксплуатацию может быть как внешней для первых пользователей, так и чисто внутренней. Каждая итерация содержит все обычные фазы жизненного цикла программного обеспечения: анализ, проектирование, реализация и тестирование. В принципе вы можете начать с самого начала: выбрать некоторую функциональность и реализовать ее, затем выбрать другую функциональность и т. д. Однако полезно потратить некоторое время на планирование разработки. Первыми двумя фазами являются начало и исследование.
В начальной фазе разрабатывается экономическое обоснование проекта и определяются его границы. Именно на этой фазе спонсор проекта принимает на себя определенные обязательства относительно дальнейшей работы. В фазе исследование уточняются более детально требования, выполняются высокоуровневый анализ и проектирование для построения базовой архитектуры и создается план для фазы построения. Даже для такого рода итеративного процесса имеется некоторая работа, которая должна быть выполнена в самом конце — в фазе внедрения. Эта работа может включать бета-тестирование, оптимизацию производительности и обучение пользователей.
Проекты отличаются между собой количеством необходимых формальностей. Сильно формализованные проекты требуют множества официальных отчетов, совещаний и согласований. В слабо формализованных проектах начальная фаза может состоять из часовой беседы со спонсором проекта и построения плана, который помещается на одной странице. Естественно, чем больше проект, тем больше он требует формальностей. Основные принципы всех фаз должны соблюдаться всегда, независимо от того, каким способом реализуется проект. Лично я пытаюсь свести зти формальности к минимуму, и мое изложение отражает это стремление. Существует изобилие излишне формализованных процессов, которые можно найти где угодно.
Ранее итерации рассматривались лишь по отношению к одной фазе— фазе построения. На самом деле итерации могут осуществляться на всех фазах и часто бывают полезным средством для выполнения большой фазы. Однако именно построение является ключевой фазой, которая разбивается на итерации. Таким образом, мы получили некоторое высокоуровневое представление о процессе разработки программного обеспечения. Теперь перейдем к деталям, чтобы получить достаточно информации о том, какое место занимают в общей картине методы, рассматриваемые далее в этой книге.
По ходу изложения я немного расскажу о самих методах и о том, когда их использовать. У тех, кто не знаком с этими методами, могут возникнуть некоторые затруднения. В атом случае пропустите непонятное место и вернитесь к нему позже. 32 Глава 2. Основы процесса разработки Начало Начальная фаза может принимать множество различных форм. Для некоторых проектов это может быть беседа за чашкой кофе: «Давайте рассмотрим размещение каталога наших услуг в Интернете».
Для более крупных проектов начальная фаза может превратиться во всестороннее изучение всех вариантов реализации проекта, которое займет месяцы. На начальной фазе разрабатывается бизнес-план проекта — определяется, какова его приблизительная стоимость и размер ожидаемого дохода. Вам следует также определить границы проекта и выполнить некоторый предварительный анализ, чтобы представить себе его размеры.
Я вовсе не стремлюсь к тому, чтобы все выполнить в начальной фазе. Начальная фаза должна занимать несколько дней работы, в течение которых следует решить, стоит ли проводить в фазе исследования более глубокий анализ, который может затянуться на несколько месяцев (см. следующий подраздел). В этот момент спонсор проекта соглашается лишь на серьезное предварительное рассмотрение проекта. Исследование Итак„проект утвержден, и начинается его выполнение. Как правило, на этой фазе у вас имеется только нечеткое представление относительно требований к системе.
Например, можно сказать следующее: Мы собираемся создать систему следующего поколения для заказчиков компании Итаттз ба!от йсасу Еотрапу и намерены использовать обьектно-ориентированную технологию для построения более гибкой системьь которая будет в большей степени ориентирована на пользователеи, в чоопноопи токую, которая будет поддерживать ик консолидированные счета. Вероятнее всего, ваше документальное описание требований будет более объемным, чем это, но в действительности оно не будет намного более содержательным.
В этот момент желательно попытаться лучше понять суть проблемы: ° Что вы на самом деле собираетесь создать2 Как вы собираетесь это сделать? Решая, какие вопросы рассматривать во время этой фазы, следует исходить, главным образом, из тех рисков, которые оказывают влияние на ваш проект. Что может привести к провалу проекта2 Чем больше риск, тем большее внимание ему следует уделить. зз Исследование Исходя из моего опыта, риски полезно классифицировать на четыре категории: 1. Риски, связанные с требованиями. Каковы требования к системеу Большая опасность заключается в том, что вы построите совсем не ту систему, которая будет выполнять вовсе не то, что нужно пользователям.
2. Технологические риски. С какими технологическими риеками вам придется столкнуться? Действительно ли позволяет выбранная вами технология реализовать ваш проект7 Каким образом следует интегрировать различные части проекта7 3. Риски, связанные с квалификацией персонала. Сможете ли вы подобрать штат сотрудников с необходимым опытом и квалификацией7 4.
Политические риски. Существуют ли политические силы, которые могут оказаться на вашем пути и серьезно повлиять на выполнение вашего проекта? В вашем случае рисков может быть и больше. Но те риски, которые по- падают в эти четыре категории, присутствуют почти всегда.
Риски, связанные с требованиями Анализ требований к системе очень важен, и это именно та область, в которой методы языка ПМЬ позволяют получить наиболее очевидные результаты. Отправной точкой при этом являются варианты использования, которые управляют процессом разработки в целом. Более детально варианты использования будут рассмотрены в главе 3, здесь же приводится лишь краткое описание их назначения. Вариант использования отражает типичное взаимодействие пользователя с системой для достижения некоторой цели. Представьте себе текстовый процессор, который я использую в данный момент. Одним из вариантов использования может быть «проверка правописания», другим — »создание предметного указателя для документа».
Важной особенностью вариантов использования является то, что каждый из них определяет некоторую функцию, которая понятна пользователю и имеет для него определенное значение. Разработчик может отреагировать, например, следующим образом: На реализацию функции создания предметного указателя у меня уидеп1 два месяца. 6стыпакже вариант использования, связанныи с поддержкои грамматическои проверки. Думаю, зто может занять п1ри месяца. В нашем распоряжении люлько три месяца на выполнение проекта — что вы «отели бы получить в первую очередь? Глава 2. Основы процесса разработки Варианты использования являются основой для общения и взаимопонимания между пользователями и разработчиками при планировании проекта. Одна из наиболее важных вещей, которые необходимо сделать на фазе исследования, — это определение всех возможных вариантов использования разрабатываемой вами системы.
На практике, разумеется, вы не в состоянии определить абсолютно все варианты. Однако следует выделить самые важные из них, которые в наибольшей степени подвержены рискам. Именно по этой причине на фазе исследования вы должны запланировать встречу с пользователем с целью формирования вариантов использования. Варианты использования не следует излишне детализировать.
Обычно я считаю, что вполне достаточно для этого текстового описания размером от одного до трех абзацев. Сам этот текст должен быть достаточно содержательным как для пользователей, чтобы они были в состоянии понять основную идею, так и для разработчиков, чтобы они хорошо представляли скрытый смысл этого описания. Однако варианты использования не дают законченное представление о картине в целом. Другой важной задачей на этой фазе является разработка общей схемы концептуальной модели предметной области. При этом сама картина бизнес-деятельности находится в голове у одного или нескольких пользователей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
