КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Обстоятельство 5.Выполняемые исследования приводят к дополнительным результатам. Иногда можно оправдать дополнительные исследования приобретенным опытом, сплочением коллектива, установлением тесных контактов с заказчиком или подтверждением проекта. Учет обстоятельств, сформулированных в предыдущем разделе, способствует устранению некоторых серьезных ошибок в инженерном программировании. Ниже приведены часто встречающиеся ошибочные рекомендации. Ошибка 1. Для исследования осуществимости, сложного ПО, работающего реальном масштабе времени, необходимо всегда применять моделирование. И действительно, в таких случаях моделирование часто играет важную роль. Тем не менее, многие модели приводят к напрасной трате усилий в соответствии с вышеуказанными рекомендациями. Некоторые модели практически бесполезны, поскольку не помогают определять множество входных воздействий (см. обстоятельство 3). Некоторые из них требуют длительных разработок, и результаты моделирования получают через неделю после принятия решения относительно метода разработки или после завершения проверки ключевых моментов проекта (см. обстоятельство 4). Ошибка 2. Необходимо всегда разрабатывать ПО дважды. Из руководства следует, что прототип (двойная разработка) является полезным инструментом. Однако обычно уже существуют прототипы разрабатываемого ПО и построение нового прототипа ничего нового не дает (см. обстоятельства 1 и 2). Ошибка 3. Разработка ПО обязательно должна проводиться методом сверху - вниз. Строго говоря, этот метод не позволяет проектировать модуль более низкого уровня до полной разработки модулей верхнего уровня, поскольку их частичное изменение из-за ошибки обычно приводит к большим затратам на переработку программ высокого уровня. Обстоятельства 1 и 2 в таком случае рекомендуют проведение дополнительного анализа степени риска на фазах анализа требований и проектирования изделия. Ошибка 4. Каждый участок программы должен быть проверен на корректность. Доказательство правильности программ остается дорогостоящим мероприятием, хотя оно полностью вытекает из обстоятельства 3. По обстоятельствам 1 и 2 применение методов доказательства правильности рекомендуется в тех случаях, когда цена неверного функционирования ПО слишком высока, например, в случаях возможной потери жизни, риска для национальной безопасности, финансового краха. Если же эта цена мала, то не следует применять метод доказательства правильности для получения дополнительной информации (см. обстоятельство 4).
|