3. Модель slim для оценки трудозатрат в проекте

Модель SLIM (Software LIfe Management – управление жизненным циклом программного продукта) для получения оценок предложил Путнэм (Lawrence H. Putnam) еще в конце 1970-х годов [20]. Эта модель строится на основании исторической БД по выполненным в данной организации проектам и поэтому полнее учитывает ее специфику. Впоследствии модель SLIM несколько раз уточнялась на основании данных от практических разработок и в современном виде определяется следующим образом.

Вводится главное уравнение для программного продукта, связывающее трудоемкость и срок разработки с производительностью, размером продукта и некоторым масштабирующим множителем B, зависящим от этого размера:

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

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

Подставляя в эти уравнения значения Размер_кода_i, Срок_i и Трудоемкость_i из исторической базы данных уже выполненных n проектов, получаем значения множителя B в n точках Размер_кода_i (1≤i≤n), по которым его можно аппроксимировать для нового n+1 проекта. Одновременно получаем и значение производительности, после чего по уже известным значениям B и Производительность получаем уравнение, связывающее оценки значений Срок и Трудоемкость для нового проекта.

Рис. 18. Экспоненциальная зависимость между сроком и трудоемкостью

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

4. Разработка спецификации требований

Спецификация требований (Requirements Specification – RS) обычно является первой плановой поставкой вместе с уточненным планом разработки; в ней исходные требования, в том или ином виде содержащиеся уже в SOW или ТЗ, выражены в достаточно объективной и точной форме, допускающей их реализуемость и тестируемость. Поскольку на основании этой спецификации уточняются трудозатраты на разработку и соответственно, уточняется (изменяется) план, то оба эти документа подлежат обязательному утверждению заказчиком.

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

Процесс управления требованиями (Requirements Management) состоит из трех групп взаимосвязанных деятельностей:

• cбор, выявление требований (requirements gathering, elicitation) имеет целью отбор кандидатов в требования из таких источников как заказчики, будущие пользователи, специалисты в данной предметной области и другие «прикосновенные лица» (stakeholders);

• анализ, упорядочивание требований (requirements analysis, triage) имеет целью определить, какие именно требования должны быть удовлетворены в свете имеющихся ресурсов, сроков, целей по прибыли и возврата вложений;

• спецификация требований (requirements specification) состоит в создании документов, определяющих наблюдаемое извне поведение будущего продукта.

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

Снизить число ошибок в выставляемых счетах, по меньшей мере, на 50%.

Другие требования могут иметь вид абстрактного описания возможной ситуации:

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

А некоторые требования могут быть наоборот, вполне конкретными:

Система должна генерировать отчет именно в этом формате.

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

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

• В – возможно достичь прямо сейчас

• О – отложить до следующей версии продукта

• И – исключить из рассмотрения ввиду невозможности

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

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

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

Продукт должен обеспечивать напряжение 220 вольт на выходном разъеме.

или

Продукт должен обеспечивать передачу стандартных контейнеров.

или

Продукт должен непрерывно отображать свое текущее состояние оператору.

Функциональность документируется через перекрестную верификационную матрицу, шаблон которой представлен в Табл. 8.

Табл. 8. Верификационная матрица для функциональных требований

Раздел документа «Требования»	Название требо-вания (его крат-кое описание)	Идентифи-катор тре-бования	Метод выявления	Уровень тести-рования для выявления	Подраздел документа «Требования»

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

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

I Inspection – инспекция

A Analysis – анализ

D Detection – обнаружение

T Review of Test Data – просмотр тестовых данных

O Other (requires explanation) – иное (дать объяснение)

и следующие пять уровней тестирования для такого выявления:

1 Unit test – модульное тестирование

2 Integration – интеграционное тестирование

3 Software DT&E (Development Test and Evaluation) – полное тестирование и оценивание разработки ПО

4 System DT&E – (Development Test and Evaluation) полное тестирование и оценивание разработки всей системы

5 Other (requires explanation) – иное (дать объяснение)

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

Табл. 9. Шаблон таблицы описания атрибутов требования

Характеристики атрибута Название атрибута	Единицы измерения	Лучший случай (улучшение не дает новой
		ценности)	Наихудший приемлемый случай

Формулировки требований могут иметь следующие свойства:

• Неоднозначность – возможны две или более интерпретации данного требования, противоречащих друг другу, например: «Привлекательный стиль»;

• Составность – требование включает в себя несколько независимых кандидатов на отдельные независимые требования, например: «Жидкокристаллический дисплей на 12 символов с подсветкой»;

• Элементарность – требование выражено ясно, точно, тестируемо и однозначно, например: «Формат символов 6×9 пикселей»;

• Условность – требование имеет другие (выводимые) требования как необходимые предусловия для его наличия, например: «Обратная совместимость с версией 2.1»;

• Выводимость – данное требование выведено как необходимое предусловие для некоторого другого требования, например: «Продукт должен использовать интерфейс XYZ (потому что его использует версия 2.1)».

Анализ требований состоит в изучении собранной информации, ее организации, расстановке приоритетов и отбора (triage) тех данных, которые затем превратятся в окончательные требования в результирующем документе «Спецификация требований». Обычные инструменты анализа – это стандартные формы, таблицы, карточки требований и т.д. Обычно анализ и отбор требований осуществляется за 4 шага: 1) форматирование; 2) группирование; 3) расстановка приоритетов; 4) выбор.

На шаге форматирования собранные данные по каждому кандидату в требования оформляются в виде карточки, шаблон которой приведен в Табл. 10.

Табл. 10. Шаблон карточки на кандидата в требования

Первоначальный кандидат в требования		Уник.№:
		Дата возникн.:
		Категория:
		Приоритет:
		Статус:
Описание:
Источник:
Обоснование:
Рейтинг заказчика:	Конкурент 1:
Целевой рейтинг:	Конкурент 2:
	Конкурент 3:

В поля карточки заносятся следующие данные:

• Уникальный № – уникальный идентификатор каждого кандидата в требования;

• Дата возникновения – дата, когда данный кандидат был создан;

• Категория – используется для группировки требований;

• Приоритет – используется для указания важности кандидата;

• Статус – состояние кандидата (активный, выбран, отложен, пересмотрен);

• Описание – текущая формулировка данного кандидата в требования;

• Источник – происхождение данного требования (например: политика организации-разработчика, промышленный стандарт, заказчик);

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

• Рейтинг заказчика – как заказчик оценивает включение этого кандидата в продукт;

• Целевой рейтинг – цель для кандидата в системе;

• Рейтинги конкурентов – как заказчик оценивает конкурентов по данному кандидату в существующих системах.

На шаге группировки кандидаты в требования объединяются в группы по категориям (В – возможно достичь прямо сейчас; О – отложить до следующей версии продукта; И – исключить из рассмотрения ввиду невозможности), после чего в категориях В и О кандидатам назначаются приоритеты по заранее выбранным критериям, например:

• удовлетворенность заказчика (качество, время разработки, стоимость);

• внутреннее давление (качество, время разработки, стоимость);

• давление конкурентов;

• доступность ресурсов.

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

• Вызывающая удовлетворение (Satisfier) – функциональность, явно затребованная заказчиком; если ее в продукте нет, то заказчик будет очевидным образом недоволен. Например: автомобиль быстро разгоняется с 20 до 60 миль в час – заказчик будет недоволен, если автомобиль разгоняется вяло, но будет удовлетворен, если разгоняется живо.

• Вызывающая разочарование (Dissatisfier) – если этой функциональности в продукте нет или уровень ее реализации недостаточен, то заказчик будет разочарован; но он не будет особенно доволен, если уровень реализации просто достаточен. Например: если автомобиль глохнет в луже, то заказчик (особенно в условиях дождливого климата) будет серьезно этим недоволен, но и не будет выражать свою радость, если автомобиль не глохнет в луже, принимая это как должное.

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

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

• Однозначность – unambiguity – формулировка не должна допускать нескольких толкований;

• Полнота – completeness – документ должен содержать подробное описание всех функций, функциональных особенностей, возможностей, ограничений и других свойств целевой системы;

• Тестируемость – testability – требование должно быть сформулировано так, чтобы его можно было протестировать (например, требование: «Система должна отвечать на запрос в разумное время» не тестируемо, тогда как требование: «Система должна отвечать на любой запрос в течение 10 секунд» вполне тестируемо);

• Согласованность – consistency – согласованное использование терминов для избегания конфликта в определениях;

• Краткость – conciseness – вся дополнительная информация (история проекта, стоимости, график и т.д.) содержится в других документах;

• Читаемость – readability – документ легко читается и понимается однозначно;

• Отслеживаемость – traceability – в документе имеется система нумерации требований для проверки того, что все требования, на которые есть ссылки, учтены в проекте и в коде;

• Реализуемость – feasibility – повторное обоснование достаточности инструментов, методик, штата и бюджета для реализации требований;

• Изменяемость – changeability – способность принимать изменения в процессе исполнения проекта.

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

Табл. 11. Некоторые слова – красные флажки в формулировке требований

Слово	Пример	Можно прочесть как
A (or AN) неопределен-ный артикль	The phone will contain a function key	1. There will be one and only one function key 2. Some key will be designated as a function key 3. There will be at least one function key
AFTER ПОСЛЕ	The dial tone comes after a beep	1. The tone immediately following the beep is the dial tone, which is thus defined by its position 2. If there's a dial tone, it comes somewhere after the beep
ALL ВСЕ	All functions are controlled by a function key	1. One function key controls the entire set of functions 2. Each function has its own function key 3. Each function is controlled by a function key, but one function key might control more than one function
ALL ВСЕ	The initial password will be all nines	1. The password will be "99" 2. The password will be "99999999" 3. Whatever the length of the password, each character will be "9"
ALL THE TIME ВСЕГДА	The lock status is set to "optional" all the time	1. The lock status is initially set to "optional" and is never reset 2. The lock status is set to "optional" every time unlock is turned on
ALSO ТАКЖЕ	The error information will be on the LCD screen also	1. Another place the error information appears is the LCD screen 2. Another type of information that appears on the LCD screen is the error information
AND И	The call ends by pressing the # key and the END key	1. The call ends by pressing the # key, and the call also ends by pressing the END key; i.e., the call ends on either a # or END key 2. The call ends on the double condition of # key and END key
BOTH ОБА	Both the # key and END key are used to terminate a call	1. Either # or END will terminate a call 2. The # and END keys together will terminate a call
BUT NOT НО НЕ	The date may be changed but not the time	1. While a feature exists to change the date, no feature can change the time. 2. Both the date and time can be changed; however, the date must be changed first
CONTINU-OUSLY ПОСТОЯННО	The plug must be placed in the wall socket continuously	1. The plug, once placed in the wall socket, must be left there forever 2. The user must continuously attempt to insert the plug into the wall socket
COULD	(см. SHOULD)
CURRENT ТЕКУЩИЙ	The current total talk time is shown on the LCD screen by pressing FN+6	1. The total is shown from the current call that is current in the real-time sense 2. The total is shown for the calls that have been made since RESET was hit
DIRECTLY НАПРЯМУЮ	An invoice is issued directly following the usage cycle	1. The invoice process is automatically invoked following the use of the product 2. The invoice process can commence once the usage cycle of the product is complete
EVERY КАЖДЫЙ	Every call is billed for airtime, even 800 numbers	1. One bill is billed for all calls 2. Each call has its unique billing rules` 3. Each call is billed, even those paid by the callee
FOLLOWING СЛЕДУЮЩИЙ	The billing policy is on the following summary page	1. The billing policy is on the next page which is the summary page 2. The billing policy is on the first summary page that follows, which may be many pages away
FROM ОТ	The function codes start from 3	1. The function codes start with the number 3 2. The function codes start with the number 4
IS GOING TO BE ДОЛЖЕН БЫТЬ	The feature is going to be available in the next release	1. The feature is available beginning with the Release 4.0 2. The feature is available now, but will not be operatinal until the next release
LARGEST НАИБОЛЬ-ШИЙ	The credit limit will be set to the largest possible value	1. The credit limit will be set toi the largest value for the individual; e.g., $2,000 2. The credit limit will be set to the largest allowable value; e.g., $25,000
LAST ПОСЛЕДНИЙ ПО МЕСТУ	The talk time total is taken from the last call	1. The talk time total is taken from the latest call 2. The talk time total is taken from the previous call
LATEST ПОСЛЕДНИЙ ПО ВРЕМЕНИ	The talk time total is taken from the latest call	1. The talk time total is taken from the call that is currently in process 2. The talk time total is taken from the call with the latest date
MAY МОЖЕТ	The password may contain an integer or a letter	1. The password must contain an integer or a letter 2. The password may contain an integer or a letter, but it might also contain something else that's not defined here
NOW СЕЙЧАС	This feature is available now	1. The feature is available beginning in Release 3.1 2. The feature is available at this point based on functions just executed
ONLY ТОЛЬКО	Digits may be only in the stored call list	1. Only digits can appear in the stored call list 2.The only list in which digits appear is the stored call list
OR ИЛИ	The call ends on a # key or an END key	1. The call ends on either a # key, or an END key, or both 2. When the call ends, one and only one of these conditions holds, either # key or END key
SAME ТОТ ЖЕ САМЫЙ	All customers have the same features available	1. All customers have the same features 2. All customer features have the same format 3. All customers can select from the same features
SHOULD СЛЕДУЕТ	The operator should place the 911 call	1. The operator must place the 911 call, otherwise the system will simply ignore the request 2. The operator ought to place the 911 call, but if not, the system has alternative actions
SMALLEST НАИМЕНЬ-ШИЙ	(см. LARGEST)
THEIR ИХ	A family unit consists of a mother and father and all their children	1. A family unit consists of a mother and her children and a father and his children 2. A family unit consists of a mother and a father and all the children whose parents are that mother and father
THEY ОНИ	(см. THEIR)
TO ДО	(см. FROM)
TOO ТОЖЕ	(см. ALSO)
UNTIL ПОКА НЕ	Calls are billed until the call with the present date has been added	1. The adding of the calls will always stop with the call with the present date 2. The adding of the calls will stop with the call with the present date, if not stopped otherwise, as by terminating the list
WE МЫ	We will create a user's guidebook	1. The user (who wrote this spec) will create a user's guidebook 2. The user and the developer (who are the readers of this spec) will create a user's guidebook
WHEN КОГДА	The word processing session ends when the sign-off command is issued	1. The only way to end a word processing session is with a sign-off command 2. If a sign-off command is issued, the word processing session ends; if not, there could be other ways of terminating
WHEN КОГДА	The talk time counter is set to zero when the RESET is pressed	1. The talk time counter is set to zero by the time the RESET is pressed 2. The talk time counter is set to zero the first time the RESET is pressed -- and only then 3. The talk time counter is set to zero whenever (each time) the RESET is pressed
WILL БУДЕТ	The function key will be pressed before the function code is set	1. Someone will have to press the function key before the function code is pressed 2. The function key must be pressed before anyone attempts to press a function code

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