Материал: 970

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

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

Постановочный этап

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

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

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

1)«интерфейсный прототип», имитирующий 1–2 важней-

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

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

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

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

Условием завершения этапа является подписание сторонами технического задания.

Уточняющий этап

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

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

На данном этапе«Руководство пользователя» фактически заменяет классическое ТЗ. Такой подход имеет ряд преимуществ:

1)включение пользователя в анализ своей рабочей документации непосредственно на первых этапах разработки программы;

2)отсутствие необходимости в одновременной правке технического задания и «Руководства пользователя»;

3)достижение соответствия создаваемой документации текущему состоянию будущего проекта.

Условием завершения этапа является подписание письменного соглашения заказчика и разработчика о принятии системы при наличии ее соответствия последней согласованной версии «Руководства пользователя», стабильности архитектуры и требований к системе(допустимые изменения в ходе следующего этапа составляют не более 20 %).

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

иопределиться с требованиями. Если этого не удается достичь

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

Стабилизирующий этап

На данном этапе устраняются недостатки в прототипах и документации и выпускается «Релиз системы». Стоимость этапа составляет примерно 50 % от общей стоимости разработки.

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

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

Внедрение

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

После доработки разработчик изменяет «Руководство пользователя», устанавливает систему на рабочей станции заказчика, проводит обучение пользователей. Пользователи должны изучить свои должностные инструкции и подтвердить возможность эксплуатации системы в соответствии с данными инструкциями.

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

принимается решение о приемке системы в промышленную эксплуатацию.

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

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

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

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

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

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

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

4.2.Базовые стандарты оценки качества программных продуктов и баз данных

Формализации показателей качества программных средств посвящена также целая серия стандартов. В базовом международном стандарте ISO/МЭК 9126:1991 «Оценка программного продукта. Характеристики качества и руководство по их применению» приведенные характеристики качества позволяют оценивать ПП с позиции пользователя, разработчика и руководителя программного проекта. В стандарте рекомендуется использовать шесть основных характеристик качества ПП(функциональные возможности, надежность, практичность, эффективность, сопровождаемость, мобильность), из которых каждая детализируется еще несколькими субпоказателями.

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

·ясность и измеряемость значений;

·независимость между используемыми показателями;

·соответствие установившимся понятиям и терминологии;

·возможность последующего уточнения и детализации. Пользователи в основном проявляют заинтересованность к

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

· наличие требуемых функций в предлагаемом программном обеспечении;