Внедрение

Внедрение

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

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

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

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

·  Производство фирмой-разработчиком по контракту с одиночным заказчиком (заказной продукт). Этот шаблон имеет несколько вариантов, а именно:

-  Фирма-разработчик создает продукт для установки на одной площадке одиночного клиента.

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

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

-  Внутренняя группа разработки программного обеспечения, которая создает программное обеспечение для нужд других отделов той же компании.

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

Основные задачи фазы внедрения:

·  Сравнить функциональность системы, разработанной на предыдущих фазах, с требованиями и выяснить степень удовлетворенности заинтересованных лиц.

·  Рассмотреть все вопросы, возникающие при работе пользователей с системой (включая недостатки, сообщамые бета-тестерами, группой приемо-сдаточного тестирования и пр.)

В этой фазе внимание сосредоточено на том, чтобы способствовать утверждению продукта в сообществе пользователей. Способ, которым это делается, зависит от шаблона (выше). Так, если программа выводится на массовый рынок, команда разработчиков распространяет бета-версию среди типичных пользователей, найденных на специальных площадках, где «водятся» бета-тестеры. Если продукт предназначен для одиночного клиента или нескольких площадок в крупной организации, команда устанавливает продукт на одной из этих площадок. В ходе проекта осуществляется обратная связь с площадкой, на которой размещена программа, с целью:

-  Определить, действительно ли система соответствует задачам бизнеса и пользователей.

-  Изучить непредвиденные риски.

-  Отметить нерешенные проблемы.

-  Найти дефекты.

-  Исправить двусмысленности и пробелы в пользовательской документации.

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

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

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

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

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

Фаза внедрения завершается выпуском продукта.

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

Менеджер проекта хочет посадить на работу с бета-тестерами несколько человек. Он может параллельно дать им работу в других проектах, но они должны быть постоянно готовы решать проблемы фазы внедрения.

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

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

-  слишком плотного графика, приводящего, в свою очередь, к эффекту «поспешил — людей насмешил»;

-  недостаточного системного тестирования и оценки в конце фазы построения;

-  невнимательности и, в результате, пропуску в фазе внедрения важной работы;

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

-  предубеждения, что переделки — это плохо, что это признание в некомпетентности.

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

Вот три «ответа» на разговоры о «все в порядке».

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

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

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

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

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

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

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

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

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

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

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

2. Руководит ли заказчик приемо-сдаточным тестированием продукта? Критерии тестирования должны быть записаны в контракте, который клиент подписывает с организацией-разработчиком. Вдобавок приемо-сдаточное тестирование продукта обычно предполагает запуск программного обеспечения в рабочем режиме в течение предусмотренного контрактом времени.

3. Достаточно ли хороши материалы для пользователей?

4. Есть ли необходимость в готовых учебных материалах (включая методические руководства для преподавателей)?

5. И наконец, считают ли пользователи и заказчики, что они удовлетворены этим продуктом?

Основные потоки работ на этой фазе не играют почти никакой роли. Как показано на рисунке

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

Кроме работы по этим пяти основным рабочим процессам, параллельно происходит деятельность по:

-  планированию итераций;

-  согласованию бизнес-плана;

-  оценке.

Что мы делаем на фазе внедрения. В ходе внедрения осуществляются следующие виды деятельности:

·  Подготовка бета-версии (или версии для приемки), созданной на фазе построения.

·  Установка (или подготовка к установке) этой версии на площадке тестирования плюс дополнительная работа на этой площадке, например перенос данных со старых систем.

·  Работа с сообщениями бета-тестеров.

·  Адаптация исправленного продукта под условия пользователей.

·  Завершение артефактов проекта.

·  Определение факта окончания проекта.

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

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

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

И снова у производителей программ есть возможность специализировать процесс в соответствии с ситуацией.

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

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

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

Реакция на результаты тестирования. Команда собирает и анализирует результаты тестирования, определяя действия, которые следует предпринять. Результаты можно разделить на два класса — относительно небольшие ошибки кодирования, которые просто нужно обнаружить и устранить (хотя в некоторых случаях это и непросто), и более серьезные проблемы, которые могут иметь множественные проявления и исправление которых может потребовать значительных усилий, вплоть до необходимости изменить архитектуру.

Ошибки. Ошибки появляются в первую очередь в результате проявления дефектов в компонентах. Эти дефекты могут быть прослежены до места их возникновения и исправлены.

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

-  Не может ли этот дефект быть связан с другими, еще не найденными?

-  Может ли он быть исправлен без изменения архитектуры или проекта?

-  Может ли он быть исправлен без внесения новых дефектов?

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

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

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

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

Отношения одного клиента. При внедрении системы у одного клиента согласно контракту имеются некоторые особенности:

-  Представители клиента, вероятно, участвуют в ранних фазах, реагируя на приращения.

-  Они наблюдают за финальными тестами на площадке разработчика.

-  Они могут принимать участие в некоторых совещаниях по оценке работ, которые отмечают вехи построения.

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

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

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

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

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

-  Перенос данных между старой системой и новой, иногда с изменением формата данных.

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

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

Когда заканчивается проект. Фаза внедрения заканчивается не тогда, когда выполнена вся работа и созданы все артефакты, а тогда, когда пользователь удовлетворен. Но когда пользователя можно считать удовлетворенным? Это зависит от отношения с рынком.

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

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

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

-  Посмотреть, выполнила ли команда поставленные перед ней задачи.

-  Установить причины невыполнения (если это произошло).

-  Добавить параметры проекта в базу данных компании для использования в будущем.

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

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

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

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

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

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

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

·  Должны быть записаны вопросы, относящиеся к разработанной системе, для отдела поддержки и команды разработки следующего выпуска. Например, часто записываются причины выбора используемой архитектуры; причины отказа от других возможных видов архитектуры также могут пригодиться следующей команде разработчиков.

·  Должны быть обдуманы вопросы, относящиеся непосредственно к процессу разработки. Например:

-  Требуется ли сотрудникам общее обучение?

-  В каких областях необходимо специальное обучение?

-  Следует ли продолжать наставничество?

-  Принесет ли опыт в специализации Унифицированного процесса то понимание, которое поможет нам в будущих проектах?

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

Основные результаты. Результаты этой фазы очень похожи на результаты фазы построения, но подкорректированные и более полные:

·  Собственно программное обеспечение, включая средства установки.

·  Юридическая документация — контракты, лицензионные соглашения, отказы от претензий, гарантии.

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

·  Полное и исправленное архитектурное описание продукта.

·  Руководства для пользователей, операторов, системных администраторов и учебные материалы.

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