2. Сложность обработки

Повторная использованость

Легкость инсталяции

Легкость эксплуатации

Разнообразные условия размещения

Простота изменений

Метрики –

Производительность = FP / затраты

Качество -

Ошибки(в ед.) / на FP в балах

Удельная стоимость-

Стоимость / на FP в балах

Документированость –

Страниц документа / на FP в балах

Добавить количество алгоритмов

Алгоритмы – при собутийном программировании (по количеству процедур обработки событий)

Достоинство:

Не зависит от языка программирования

Легко вычеслить на любом этапе разработки

Недостатки:

Субъективные данные – косвенное вычисление

Взаимосвязь loc и FP оценок:

Количество операторов на один FP

Асемблер

Обычный Си 128

С++ 64

Visual C++ 34

Делфи 29

Перл 21

Цель IEEE

Требования в соотвецтвии со стандартными:

1. Введение С(це)

2. Общее описание С

Эти требования – это проблемма заказчика.

3. Детализация – конкретные требования Д

4. Сопроваждающая информация С+Д

Формулировка требований

- Четкость и однозначность описания.

- Доступность

- Номер должен быть

- Детализующая подтверждающая текстовка

- Предусматриватся в проэкте

- Учитыватся в коде

- Тестирование как отдельно, как и совместно с другими требованиями

- Тестирование после полной сборки приложения

Процесс аналализа требования. Типовая схема

Шаг 1:

Идентифицировать заказчика

Шаг 2:

Беседа с представителями заказчика

- Желания и потребностти заказчика

- Примерный интерфейс пользователя

- Конфигурация оборудования

- Средство поддержки

Шаг 3 :

Написать С-требования

Шаг4:

Проверка С-требований

Шаг 5:

D-требования

Метрики критерии:

1. Время

2. Количество страниц С-требований

3. Время затраченое на получение одной страницы( Общение с заказчиком)

4. Оценка качества результатов

- Экспертная балы от 1 до 10

5. Оценка дефектов по результатом проверки требований

Приверная структура с-требований

Введение

1. Цель

2. Область применения

3. Определение термина и сокращения

4. Ссылки

5. Обзор

Общее описание

1. Пользовательские интерфейсы

2. Системные интерфейсы

3. Аппаратные интерфейсы

4. Программные интерфейсы

5. Коммунникационные интерфейсы

6. Ограничение по памяти

7. Операции

8. Требования по адаптации

…

2.3 Пользовательские характеристики

2.4 Ограничение

2.5 Предположение независимости

2.6 Распределение требований

Недостаток:

- Нужно добовлять еще ООП

Стоимость обнаружение ошибки в 20-50 раз меньше чем в процессе разработки.

Результат анализа требований: понимание, согласованое с заказчиком, разробатываемой программы(подпишет контракт)

Источники возникновения требований:

1. Значительный процент требований - в результате опроса представителей заказчика (причем, этот процент отличается для разных задач)

- Где нужно опрашивать людей, и четкие разщеты

Где брать требования(Заинтересованые лица):

…

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

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

У каждого игрового персонажа есть набор характеристик: сила, интелект…

Каждая характеристика имеет численное значение

Персонажи отличаются когда находятся в одной игровой зоне.

И могут затем вступать в контакт.

Результат контакта , зависит от значений характеристик и от зоны, в которой произошел контакт.

Нужды заказчика отличаются от его желаний.

Реально чтобы было автосохранение

Порядок проведения опроса и его документирование:

1. Подготовка к интервью(приоритеты)

2. План интервью с фиксированым временем

3. Желательно, 2 хотябы человека из разработчиков

4. Желательно, запись интервью

Проведения интервью

1. Активное провидение

2. Необходимо понять желания заказчика

3. Изучение нужд заказчика

Варианты использования:

1. Потоки данных

2. Диаграммы переходов состояний

3. Спланировать следующую встречу

После интервью:

1. Составить черновик С-требований

2. Отправить заказчику

-- требования могут быть противоричивыми у разных заказчиков, поэтому нужно выбрать приоритеты(кто главный)

-- с записью нужно предуприждать

--