Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Цикл создания и развития программ для ЭВМ



Каскадная модель

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

Эту последовательность можно представить в виде так называемой каскадной модели.

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

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

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

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

Спиральная модель

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

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

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

Обратная разработка

Иногда возникают ситуации, когда «спираль» ПО необходимо «раскрутить» в обратном направлении: от программы к ее проекту или от проекта к задаче. Необходимость этого процесса (он называется обратной разработкой) может быть вызвана разрывом в преемственности разработки программы или необходимостью интеграции давно разработанной программы в иную систему.

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

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.