Введение
Любая система имеет как свое начало во времени, так и завершение. Для краткого обозначения этого обстоятельства говорят, что она имеет свой специфический жизненный цикл. Проще всего двухфазный цикл (адаптация, деградация), сложнее трехфазный цикл (рост, расцвет, упадок). Эти фазы можно выделить у любой системы. Просто они будут называться по-разному в зависимости от специфики системы.
Цель работы
Дать определение понятия жизненный цикл системы, рассмотреть жизненного цикла автоматизированной системы, характеристика методов описания системы
Жизненный цикл системы
Жизненный цикл автоматизированной системы включает восемь стадий, каждая из которых может подразделяться на этапы. Этапы могут выполняться одновременно (параллельно) – тогда их можно рассматривать как каналы жизненного цикла процесса разработки автоматизированной системы. Первыми в жизненном цикле АС идут предпроектные стадии, которые включают стадию формирования требований к системе и стадию разработки концепции системы. Затем идет стадия разработки технического задания. Затем – собственно стадии проектирования – разработка эскизного, затем – технического проектов, затем – разработка рабочей документации, ввод системы в действие, и – стадия сопровождения системы. Все стадии, вплоть до сопровождения (эксплуатации системы после ее ввода в действие) являются для заказчика системы затратными. Отдача от системы может быть получена только на стадии эксплуатации системы.
Кривая пользы от образца системы
Системы создают для реализации их полезных функций. Ясно, что, создавая систему, приходится потратиться в надежде на последующую окупаемость расходов.
На приведенном ниже графике (Рис.1) изменение получаемой от системы (изделия) пользы по жизненному циклу, начиная с разработки (вложения в разработку) вплоть до окончания использования. Кривая может служить основой для оценки эффективности разработанной системы, как отношения затрат на разработку к полученной пользе от системы. В полной мере эта кривая описывает пользу от автоматизированной системы по жизненному циклу ее создания.
Рис.1 Кривая пользы от образца системы
Рассмотрим жизненный цикл образца в целом. Все его фазы, кроме фазы промышленной эксплуатации, по существу убыточны. На всех фазах имеют место немалые затраты, и лишь на одной из них происходит возврат вложенных средств и получение прибыли. На рис. 1 это обстоятельство показано графически. Здесь по горизонтали отложено время t по жизненному циклу, по вертикальной оси – польза от системы P(t).
Кривая 1 на рис.1 является как бы канонической (опорной для осмысления) кривой получения пользы от образца по его жизненному циклу. Часть кривой, лежащая ниже оси абсцисс, описывает затраты на проектирование и начало производства 
. Затем, вплоть до точки максимума, кривая описывает получение прибыли от использования - 
, затем – падение пользы и - окончание эксплуатации. И эффект от системы определяется как e= 
.
Кривая 2 описывает пользу от системы, разработанной с заимствованием опыта производства аналогичных изделий - начальные затраты за счет этого будут меньше, а значит и общая польза выше – точка оптимума кривой 2 выше оптимума кривой 1.
Кривая 3 описывает пользу от системы, разработанной и используемой по лицензии - затраты на подготовку производства минимальны (по сравнению с кривыми 1 и 2), но поскольку производство системы начато с запозданием, то она быстрее морально устаревает, вытесняется новыми типами систем аналогичного назначения, и следовательно дает меньшую прибыль. Пример – клоны компьютера IBM PC.
Кривые 4 и 5 характеризуют пользу от систем, разработанных с сильным запозданием
(кривая 4) и безнадежно устаревших: не имеющих перспектив на рынке (кривая 5). Если начать разработку и внедрение образца с отставанием, например, от зарубежных аналогов, то прибыль от эксплуатации образца не будет уже равна максимально возможной учредительской прибыли.
Как видно из рис. 1, важно предсказать наиболее выгодные моменты начала и завершения эксплуатации систем данного типа, поскольку при преждевременном внедрении требуются повышенные затраты, а при запоздалом, теряется часть прибыли, что приносит большие убытки. Поэтому выдвигаются следующие требования к характеристикам фаз жизненного цикла образца:
· удлинение времени полезной жизни образца, что для АС реализуется как модернизация и развитие и базируется на принципах системности и открытости разработки. Известны примеры АС работающие уже на четвертом поколении техники;
- сокращение реализационного периода разработки, что для АС реализуется, как синтез нескольких стадий жизненного цикла разработки: вместо эскизного, технического проектов и рабочей документации разрабатывают техно-рабочий проект;
· сокращение времени вывода убыточного образца из экономической сферы (время замены). Для АС – это перевод на новые технические платформы и более совершенное программное обеспечение, например ПО с открытым кодом.
Зачастую запаздывают с началом разработки (в случае конкурирующих или противоборствующих образцов), тогда реализационный цикл требуется проводить (см. рис. 1) в сжатые сроки и по возможности с наименьшим перерасходом средств. Необходимо быстро внедрять и увеличивать количество действующих систем. Это, в свою очередь, означает, что-либо системы должны быть высоконадёжны (и поэтому их парк растёт пропорционально выпуску), либо необходим их массированный выпуск, который перекроет их естественную убыль из-за слома. Отметим, что аналогичный эффект существует в живой природе: вид может выживать либо за счет плодовитости, либо за счет высокой живучести отдельных организмов.
Рассмотрим жизненный цикл разработки автоматизированной системы как последовательность укрупненных этапов. В стандартном виде – это последовательность этапов во времени, когда по результатам одного этапа начинается следующий. Он условно называется моделью "водопада" или "каскадной" моделью. Схематично это представлено на рис. 2.
· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
· выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении АС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи.
Рис. 2 Схема каскадного подхода
Однако реально в процессе создания АС постоянно возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. Реальный процесс создания АС принимает следующий вид (рис.3):
Рис. 3 Реальный процесс создания АС на базе каскадной модели
Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model).
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Другой недостаток - такое проектирование АС ведет к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников.
В спиральной модели ЖЦ (рис.4), делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.
Рис. 4 Спиральная модель ЖЦ
Каждый виток спирали соответствует созданию нового фрагмента или версии АС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также "Продолжающимся проектированием". Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", - rapid prototyping approach или "fast-track".
Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости различных фрагментов АС. Основная проблема спирального цикла - определение момента перехода на следующий этап. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Эта методология является наиболее распространенной в текущее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework). Теперь создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточняя характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируем мы только то, что можем предвидеть, и разрабатываем то, что запланировано, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы.
Вывод: для этого нужны очень большие средства. Если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участвовать в проекте: архитекторы, программисты, тестировщики, инструкторы и т. д. Более того, усилия различных групп должны быть синхронизированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения. Разработка ведется в соответствии с концепцией MDA (Model Driven Architecture - Определяемая Моделью Архитектура), одобренной консорциумом OMG и предполагает использование языка UML в качестве средства "специфицирования, создания, визуализации и документирования систем". Естественно, пользы от нарисованных на бумаге диаграмм, мало, когда речь идет о MDA. Этот подход предполагает, что код и документация являются просто разными аспектами одной сущности - модели системы и должны быть постоянно синхронизованы. Соответственно, мы понимаем, что без специальных средств не обойтись, но хорошие CASE (Computer Aided Software Engineering - Разработка ПО с помощью компьютера) инструменты стоят просто умопомрачительных денег, а более дешевые не приводят к автоматизации всего спектра задач. Если прибавить стоимость высококлассных специалистов, способных извлечь пользу из столь высокотехнологичных инструментов и произвести анализ, можно обнаружить, что все это становиться «барьером» для вхождения малых и средних предприятий в отрасль
Методы описания систем
Методы описания систем классифицируются в порядке возрастания формализованности от качественных методов до количественного систематизирования. В качественных методах основное внимание уделяется организации постановки задачи, новому этапу её формализации, формированию вариантов, выбору подходов к оценке вариантов. Количественные методы, связанные с анализом вариантов с их количественными характеристиками корректности и точности. Между этими крайними классами методов имеются методы, которые стремятся охватить оба этапа, среди них: кибернетический подход к разработке адаптивных систем управления, проектирования, принятия решений, информационный подход моделирования систем, системно – структурный подход, метод ситуационного моделирования и метод имитационного динамического моделирования.
