Технология разработки программного обеспечения

периодичность усовершенствования в целях продления цикла

жизни изделия и т.д.

Обычно элементы стратегии охватывают длительный интервал

(5-10 лет).

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

Таблица 8.1 – Конфигуратор

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

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

171

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

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

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

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

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

8.2.5. Опытный образец изделия

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

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

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

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

пользуют правило: считать опытный образец первой версией реального изделия и тут же запланировать реализацию второй версии.

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

172

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

8.2.6. Организация планирования в фазе исследования

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

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

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

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

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

173

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

Анализ осуществимости

Конструирование

Программирование

Спецификации утверждены Спецификации составлены Требования утверждены

Требования сформулированы Ресурсы распределены

Необходимость разработки изделия признана Компоновка завершена

Независимые испытания начались Начато изготовление изделия

Изделие передано на распространение Изделие снято с производства

Рис. 8.5 – Жизненный цикл программного изделия

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

174

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

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

8.2.7. Организация планирования в стадии анализа осуществимости

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

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

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

копределенному времени.

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

175

8.2.8. Организация планирования в фазах конструирования и кодирования

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

8.2.9. Организация планирования в фазах оценки и использования

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

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

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

176

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

8.2.10. Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия

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

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

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

Фаза I. Следует ли вкладывать ресурсы в продолжение анализа осуществимости проекта?

Фаза II. Обоснована ли реализуемость проекта и следует ли расходовать средства на проектирование?

Фаза III. Удовлетворяет ли проект потребностям пользователя в текущий момент времени и следует ли выделять средства для завершения работ?

Фаза IV. Закончена ли разработка изделия и можно ли ему дать объективную независимую оценку?

Фаза V. Достаточно ли высоко качество программного изделия для его поставки пользователю?

Фаза VI. Можно ли прекратить обслуживание программного изделия?

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

Независимо от того, кто проводит обзор, группа планирования обладает решающим голосом в фазовых обзорах I, II, V и VI.

Перечень вопросов, подлежащих рассмотрению в каждом обзоре, строго стандартизирован:

Строго ли выполняются планы?

Строго ли соблюдаются все предварительные технические условия?

Идет ли разработка проекта в соответствии с намеченным графиком?

Не превышают ли расходы, связанные с проектированием, определенные статьи бюджета?

Обеспечены ли все необходимые взаимодействия?

Существуют ли какие-либо оправдания замеченным нарушениям?

Каков элемент случайности, присутствующий в планах?

В чем состоят основные трудности?

Каковы возможные пути преодоления основных трудностей?

С каким риском связано продолжение работ?

С каким риском связано прекращение работ?

Удовлетворяет ли программное изделие в его нынешнем виде те-

кущим требованиям?

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

178

Продолжение работ по плану.

Пересмотр планов и спецификаций с последующим продолжением работ согласно новым установкам.

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

Прекращение работ.

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

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

8.3. Организация разработки программного изделия

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

179