Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
PGTU / 5 семестр / Надежность / Nadezhnost_4-ya_redaktsia.doc
Скачиваний:
334
Добавлен:
29.03.2015
Размер:
12.07 Mб
Скачать

Цели проекта

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

1. Ориентировочная стоимость каждого процесса.

2. Календарный план проекта.

3. Цели для каждого процесса тестирования.

4. Степень адаптируемости или расширяемости, которая должна быть достигнута.

5. Сопровождение создаваемой системы, которое необходимо учи­тывать при разработке.

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

7. Внутренняя документация при работе над проектом.

8. Критерии для оценки готовности проекта к использованию.

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

Крайне важно, чтобы цели были четкими, явными, разумными и из­меримыми.

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

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

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

Оценка целей

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

Главное требование – сопоставить цели с требованиями, чтобы убе­диться, что все требования правильно переведены на язык целей. Так как этот вопрос очень важен, каждая цель должна быть лично оценена пред­ставителями нескольких уровней руководства, как в организации-пользо­вателе, так и в организации-разработчике.

Соседние файлы в папке Надежность