Билет 24

1. Применение процедуры определения дохода от информации в инженерном программировании иус.

Приведенная процедура помогает решению многих ключевых проблем выбора в инже­нерном программировании следующего типа.

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

1. Какие средства надо затратить на фазе исследования осуществимости проекта прежде чем остановить свой выбор на конкретном варианте проекта?

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

3. Какие средства надо затратить на анализ риска прежде чем конкретизировать требования на изделие и пути реализации проекта?

4. Какие средства надо затратить на верификацию и подтвер­ждение преж­де чем при­ступить к эксплуатации программного изделия?

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

Обстоятель­ство 1.

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

Об­стоятельство 2.

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

Обстоятельство 3.

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

Обстоятельство 4.

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

Обстоятельство 5.

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

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

Ошибка 1.

Для исследования осуществимости, сложного ПО, работающего реальном масштабе времени, необходимо всегда применять моделирование. И действительно, в таких случаях моделирование часто играет важную роль. Тем не менее, многие модели приводят к напрас­ной трате усилий в соответствии с вышеуказанными рекомендациями. Некоторые модели практически бесполезны, поскольку не помогают определять множество входных воздейст­вий (см. обстоятельство 3). Некоторые из них требуют длительных разработок, и результаты моделирования получают через неделю после принятия решения относительно метода разра­ботки или после завершения проверки ключевых моментов проекта (см. обстоятельство 4).

Ошибка 2.

Необходимо всегда разрабатывать ПО дважды. Из руководства следует, что прототип (двойная разработка) является полезным инструментом. Однако обычно уже существуют прототипы разра­батываемого ПО и построение нового прототипа ничего нового не дает (см. обстоятельства 1 и 2).

Ошибка 3.

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

Ошибка 4.

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

Ошибка 5.

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