ЛЕКЦИЯ 10

ЖИЗНЕННЫЙ ЦИКЛ СИСТЕМЫ

Модели ЖЦ и его основные этапы

При описании жизненного цикла системы используются следую­щие понятия:

процесс - цепочка последовательно выполняемых работ;

этапы - последовательные отрезки времени, в течение кото­рого выполняются работы . В течение этапа могут выполняться работы, относящиеся к разным процессам. В основе деятельности по созданию и использованию автомати­зированной системы управления предприятием (АСУП) лежит по­нятие ее жизненного цикла (ЖЦ). ЖЦ является моделью создания и использования АСУП, отражающей ее различные состояния, начи­ная с момента возникновения необходимости в данном изделии и заканчивая моментом его полного выхода из употребления у всех без исключения пользователей.

Традиционно выделяются следующие основные этапы ЖЦ АСУП:

анализ требований;

проектирование;

программирование/внедрение;

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

эксплуатация и сопровождение.

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

Существующие модели ЖЦ определяют порядок исполнения эта­пов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:

1. Каскадная модель (в 70-80-е годы) - предполагает переход на следующий этап после полного окончания работ по предыдущему этапу и характеризуется четким разделением данных и процессов их обработки.

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

3. Спиральная модель (в 86-90-е годы) - делает упор на началь­ные этапы ЖЦ: анализ требований, проектирование специфика­ций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его каче­ство, планируются работы следующего витка спирали. Таким обра­зом углубляются и последовательно конкретизируются детали про­екта и в результате выбирается обоснованный вариант, который доводится до реализации.

Специалистами отмечаются следующие преимущества спираль­ной модели:

накопление и повторное использование программных средств, моделей и прототипов;

ориентация на развитие и модификацию системы в процессе ее проектирования;

анализ риска и издержек в процессе проектирования

. Отметим, что главная особенность индустрии АСУП состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проек­тирование) при относительно невысокой сложности и трудоемкос­ти последующих этапов. Более того, нерешенные вопросы и ошиб­ки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, могут лишить успеха.

Анализ требований

Анализ требований является первой фазой разработки АСУП, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на воп­рос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.

Список требований к АСУП должен включать:

Совокупность условий, при которых предполагается эксплуа­тировать будущую систему (аппаратные и программные ре­сурсы, предоставляемые системе; внешние условия ее функ­ционирования; состав людей и работ, имеющих к ней отно­шение);

Описание выполняемых системой функций;

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

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

Архитектуру системы, ее функции, внешние условия, распре­деление функций между аппаратной и программной частями (ПЧ);

Интерфейсы и распределение функций между человеком и системой;

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

Полную функциональную модель требований к будущей сис­теме с глубиной проработки до уровня каждой операции каж­дого должностного лица;

Спецификации операций нижнего уровня;

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

Концептуальную информационную модель требований;

Пакет отчетов и документов по информационной модели;

Архитектуру системы с привязкой к концептуальной инфор­мационной модели;

Предложения по оргштатной структуре для поддержки сис­темы.

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

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

Описать, «увидеть» и скорректировать будущую систему до того, как она будет реализована физически;

Уменьшить затраты на разработку и внедрение системы;

Оценить разработку по времени и результатам;

Достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, програм­мистами и т. д.);

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

2. Модель требований полностью независима и отделяема от кон­кретных разработчиков, не требует сопровождения ее создателями и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации систе­мы на основе модели требований, она может быть положена «на пол­ку» до тех пор, пока в ней не возникнет необходимость.

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

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

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

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

Аналитик не всегда располагает исчерпывающей информаци­ей для оценки требований к системе с точки зрения заказ­чика;

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

Аналитик сталкивается с чрезмерным количеством подробных сведений как о предметной области, так и о новой системе;

Традиционная (текстовая) спецификация системы из-за объе­ма технических терминов часто непонятна заказчику;

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

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

Структурные методы анализа

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

Разбиение на уровни абстракции с ограничением числа эле­ментов на каждом из уровней (обычно от 3 до 7, при этом верхняя граница соответствует возможностям человеческого мозга воспринимать определенное количество взаимоувязан­ных объектов, а нижняя выбрана из соображений здравого смысла);

Ограниченный контекст, включающий лишь существенные на каждом уровне детали;

Использование строгих формальных правил записи;

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

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

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

Облегчается тестирование таких систем. Если появляется пло­хой звук одной из колонок, можно поменять колонки места­ми. Если неисправность переместилась с колонкой, то имен­но она подлежит ремонту; если нет, тогда проблема в усили­теле, магнитофоне или местах их соединения.

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

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

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

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

Каждый черный ящик должен реализовывать единственную функцию системы;

Функция каждого черного ящика должна быть легко понимае­ма независимо от сложности ее реализации (например, в си­стеме управления ракетой может быть черный ящик для рас­чета места ее приземления: несмотря на сложность алгорит­ма, функция черного ящика очевидна - расчет точки при­земления);

Связь между черными ящиками должна вводиться только при наличии связи между соответствующими функциями систе­мы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой - для расчета налогов необходима связь между этими черными ящиками: размер заработанной платы требуется для расчета налогов);

Связи между черными ящиками должны быть простыми, на­сколько это возможно, для обеспечения независимости меж­ду ними.

Второй важной идеей, лежащей в основе структурных методов," является идея иерархии. Для понимаемости сложной системы недо­статочно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Все сложные системы Вселенной организованы в иерархии. Да и сама она включает галактики, звездные системы, планеты, молеку­лы, атомы, элементарные частицы. Человек при создании сложных систем также подражает природе. Любая организация имеет дирек­тора, заместителей по направлениям, иерархию руководителей под­разделений, рядовых служащих. Таким образом, второй прин­цип структурного анализа (принцип иерархического упорядочения) в дополнение к тому, что легче понимать проблему, если она разби­та на части, декларирует, что устройство этих частей также суще­ственно для понимания. Понимаемость проблемы резко повышается при организации ее частей в древовидные иерархические структу­ры, т. е. система может быть понята и построена по уровням, каж­дый из которых добавляет новые детали.

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

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

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

функции, которые система должна выполнять,

отношения между данными,

зависящее от времени поведение системы (аспекты реальноговремени).

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

DFD (Data Flow Diagrams) - диаграммы потоков данных совмес­тно со словарями данных и спецификациями процессов (мини-специ­фикациями);

ERD (Entity-Relationship Diagrams) -диаграммы «сущность -связь »;

STD (State Transition Diagrams) - диаграммы переходов состо­яний.

Классическая DFD показывает внешние по отношению к систе­ме источники и стоки (адресаты) данных, идентифицирует логи­ческие функции (процессы) и группы элементов данных, связыва­ющие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется дос­туп. Структуры потоков данных и определения их компонент хра­нятся и анализируются в словаре данных. Каждая логическая функ­ция (процесс) может быть детализирована с помощью DFD нижне­го уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи специфика­ции процесса (мини-спецификации). Содержимое каждого храни­лища также сохраняют в словаре данных, модель данных хранили­ща раскрывается с помощью ERD. В случае наличия реального вре­мени DFD дополняется средствами описания зависящего от време­ни поведения системы, раскрывающимися с помощью STD. Эти взаимосвязи показаны на рис. 20.

Необходимо отметить, что для функционального моделирова­ния наряду с DFD достаточно часто применяется и другая нота­ция - SADT (точнее, ее стандартизованное подмножество IDEFO). Сравнительный анализ этих двух подходов к моделированию фун­кций системы будет приведен ниже.

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

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

Рис. 20

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

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

В настоящее время успешно используются практически все из­вестные методологии структурного анализа, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна-Сарсона (Gane-Sarson), структурного анализа и проектирования Йодана-Де Марко (Yourdon-DeMarko), развития систем Джексо­на (Jackson), развития структурных систем Варнье-Орра (Warmer- Orr), анализа и проектирования систем реального времени Уорда- Меллора (Ward-Mellor) и Хатли (Hatley), информационного моде­лирования Мартина (Martin).

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

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

по отношению к школам - Software Engineering (SE) и Information Engineering (IE);

по порядку построения модели - процедурно-ориентирован­ные и информационно-ориентированные;

по типу целевых систем - для систем реального времени (СРВ) и информационных систем (ИС).

SE является универсальной дисциплиной разработки програм­мных систем всех типов (ИС, СРВ). IE является дисциплиной пост­роения ИС вообще, а не только их программной компоненты и вклю­чает этапы более высокого уровня (например, стратегическое пла­нирование), однако на этапе анализа требований к программной части эти дисциплины аналогичны.

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

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

Таблица 2

Средствами поддержки этих особенностей и различаются соответ­ствующие структурные методологии. Необходимо отметить, что для целей анализа требований к системам реального времени использу­ются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, матрицы состояний/ событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для анализа требований к ин­формационным системам. Более того, известные методологии ана­лиза и проектирования СРВ (в частности, методологии Хатли и Уор-да-Меллора) базируются на перечисленных методологиях анализа и проектирования ИС, расширяя их соответствующими диаграмм­ными техниками.

В табл. 3 приведена классификация наиболее часто используемых методологий в соответствии с вышеперечисленными признаками (данные по частоте использования получены на основе анализа ин­формации по 127 CASE-пакетам).

Как уже отмечалось, наиболее существенное различие между разновидностями структурного анализа заключается в методах и сред­ствах функционального моделирования. С этой точки зрения все раз­новидности структурного системного анализа могут быть разбиты на две группы: применяющие методы и технологию DFD (в различ­ных нотациях) и использующие SADT-методологию. По материа­лам наиболее авторитетной в рассматриваемой области исследовательской компании CASE Consulting Group соотношение примене­ния этих двух разновидностей структурного анализа на практике составляет 90% для DFD и 10% для SADT.

Таблица 3

Предваряя сравнительный анализ DFD- и SADT-подходов , в ка­честве примера рассмотрим верхний уровень модели требований к системе автоматизации управления компанией, занимающейся рас­пределением товаров по заказам (рис. 21 и рис. 22 соответственно). Заказы подвергаются входному контролю и сортировке. Если заказ не отвечает номенклатуре товаров или оформлен неправильно, то он аннулируется с соответствующим уведомлением заказчика. Если заказ не аннулирован, то определяется, имеется ли на складе соот­ветствующий товар. В случае положительного ответа выписывается счет к оплате и предъявляется заказчику, при поступлении платежа товар отправляется заказчику. Если заказ не обеспечен складскими запасами, то отправляется заявка на товар производителю. После поступления требуемого товара на склад компании заказ становится обеспеченным и повторяет вышеописанный маршрут.

Сравнительный анализ этих двух разновидностей методологий проводится по следующим параметрам:

адекватность средств рассматриваемой проблеме;

согласованность с другими средствами структурного анализа;

интеграция с последующими этапами разработки (и прежде всего с этапом проектирования).

1) Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. В нашем случае методологии применяются к автоматизиро­ванным системам управления предприятием, а не к системам вооб­ще, как это предполагается в SADT. Для рассматриваемых задач DFD вне конкуренции.

Во-первых, SADT-диаграммы значительно менее выразительны и удобны для моделирования АСУП (сравните рис. 21 и рис. 22). Так, дуги в SADT жестко типизированы (вход, выход, управление, меха­низм). В то же время применительно к АСУП стирается смысловое различие между входами и выходами, с одной стороны, и управле­ниями и механизмами, с другой: входы, выходы, механизмы и уп­равления являются потоками данных и/или управления и правила­ми их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и не­двусмысленным.

ких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой систе­мы с внешним миром).

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

2) Согласованность. Главным достоинством любых моделей явля­ется возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моде­лирования. Согласование SADT-модели с ERD и/или STD практи­чески невозможно или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являют­ся согласованными представлениями различных аспектов одной и той же модели (см. рис. 20). В табл. 4 отражена возможность такой интеграции для DFD- и SADT-моделей.

Таблица 4

Отметим, что интеграция DFD-STD осуществляется за счет рас­ширения классической DFD специальными средствами проектиро­вания систем реального времени (управляющими процессами, по­токами, хранилищами данных), и STD является детализацией уп­равляющего процесса, согласованной по управляющим потокам и хранилищам. Интеграция DFD-ERD осуществляется с использова­нием отсутствующего в SADT объекта - хранилища данных, струк­тура которого описывается с помощью ERD и согласуется по соот­ветствующим потокам и другим хранилищам на DFD.

3) Интеграция с последующими этапами. Важная характеристика методологии - ее совместимость с последующими этапами приме­нения результатов анализа (и прежде всего с этапом проектирова­ния, непосредственно следующим за анализом и опирающимся на его результаты). DFD могут быть легко преобразованы в модели про­ектирования (структурные карты) - это близкие модели. Более того, известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логич­ный и безболезненный переход от этапа анализа требований к проек­тированию системы. С другой стороны, неизвестны формальные ме­тоды преобразования SADT-диаграмм в проектные решения АСУП.

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

Жизненный цикл - это не временной период существования, а процесс последовательного изменения состояния, обусловленный видом производимых воздействий (Р 50-605-80-93) .

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

История концепции жизненного цикла

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

Типовые модели жизненного цикла системы

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

Некоторые специалисты по системной инженерии предлагают рассматривать модель жизненного цикла системы, на основе следующих трех источников: модель управления материально-техническим обеспечением Министерства Обороны США (МО США) (DoD 5000.2), модель стандарта ISO/IEC 15288 и модель Национального общества профессиональных инженеров (NSPE) :71 .

Типовая модель жизненного цикла по стандарту ISO/IEC 15288

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

В стандарте в качестве примера были приведены следующие стадии жизненного цикла:

1. Замысел.
2. Разработка.
3. Производство.
4. Применение.
5. Поддержка применения.
6. Прекращение применения и списание.

В версии стандарта от 2008 года (ISO/IEC 15288:2008) примеры стадий жизненного цикла отсутствуют .

Типовая модель жизненного цикла по версии Министерства обороны США

Для управления рисками в области применения передовых технологий, и сведения к минимуму дорогостоящих технических или управленческих ошибок, МО США разработало руководство, содержащее все необходимые принципы разработки систем. Эти принципы вошли в специальный перечень директив - DoD 5000.

Модель жизненного цикла системы управления материально-техническим обеспечением по версии МО США состоит из пяти стадий :71:

1. Анализ.
2. Разработка технологии.
3. Инженерная и производственная разработка.
4. Производство и развертывание.
5. Функционирование и поддержка.

Типовая модель жизненного цикла системы Национального общества профессиональных инженеров (NSPE)

Данная модель адаптирована для развития коммерческих систем. Данная модель в основном направлена на развитие новых продуктов, обычно являющихся результатом технического прогресса. Модель NSPE представляет собой альтернативный взгляд на модель версии МО США. Жизненный цикл по модели NSPE разбивается на шесть стадий :72:

1. Концепция.
2. Техническая реализация.
3. Разработка.
4. Коммерческая валидация и подготовка производства.
5. Полномасштабное производство.
6. Поддержка конечного продукта.

Типовая модель жизненного цикла продукции по Р 50-605-80-93

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

Для промышленной продукции гражданского назначения предложены следующие стадии:

1. Исследование и проектирование.
2. Изготовление.
3. Обращение и реализация.
4. Эксплуатация или потребление.

В рамках жизненного цикла промышленной продукции гражданского назначения предложено рассматривать 73 вида работ и 23 типа стейкхолдеров («участников работ» по терминологии документа).

Для промышленной продукции военного назначения предложены следующие стадии:

1. Исследование и обоснование разработки.
2. Разработка.
3. Производство.
4. Эксплуатация.
5. Капитальный ремонт.

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

Типовая модель жизненного цикла программного обеспечения

Стадии жизненного цикла системы и их составные фазы, представленных на рисунке «Модель жизненного цикла системы», относятся к большинству сложных систем, в том числе к тем, которые содержат программное обеспечение со значительным объемом функциональных возможностей на уровне компонентов. В программно-интенсивных системах, в которых программное обеспечение выполняет практически все функции (как например в современных финансовых системах, в системах бронирования авиабилетов, в глобальной сети интернет, и в др.), как правило жизненные циклы схожи по содержанию, но часто усложняются итерационными процессами и прототипированием :72-73 .

Основные стадии жизненного цикла системы (Kossiakoff, Sweet, Seymour, Biemer)

Как показано на рисунке «Модель жизненного цикла системы», модель жизненного цикла системы содержит 3 стадии. Первые 2 стадии приходятся на разработку, а третья стадия охватывает пост-разработку. Эти стадии показывают более общие переходы из состояния в состояние, в жизненном цикле системы, а также показывают изменения в типе и объеме действий, вовлеченных в системную инженерию. Стадии представляют собой :73:

• стадию разработки концепции;
• стадию технической разработки;
• стадию пост-разработки.

Стадия разработки концепции

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

Основные цели стадии разработки концепции :74:

1. Провести исследования, установив, что является необходимым для новой системы, а также установив техническую и экономическую целесообразность данной системы.
2. Изучить потенциально возможные концепции системы, а также сформулировать и подвергнуть валидации набор требований к производительности системы.
3. Выбрать наиболее привлекательную концепцию системы, определить её функциональные характеристики, а также разработать детальный план последующих стадий проектирования, производства и оперативного развертывания системы.
4. Разработать любую новую технологию, подходящую для выбранной концепции системы и подвергнуть валидации её способности удовлетворять потребности.

Стадия технической разработки

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

Основными целями стадии технической разработки являются :74:

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

Стадия пост-разработки

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

ЖЦИС - это период создания и использования ИС, начиная с момента возникновения потребности в ИС и заканчивая моментом полного её выхода из эксплуатации.

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

Традиционно выделяются следующие основные этапы ЖЦ ПО :

• анализ требований;
• проектирование;
• кодирование (программирование);
• тестирование и отладка;
• эксплуатация и сопровождение.

Стадии жизненного цикла информационной системы

1. Предпроектное обследование
   • 1.1. Сбор материалов для проектирования; при этом выделяют формулирование требований, изучение объекта автоматизации, даются предварительные выводы предпроектного варианта ИС.
   • 1.2. Анализ материалов и разработка документации; обязательно даётся технико-экономическое обоснование с техническим заданием на проектирование ИС .
2. Проектирование
   • 2.1. Предварительное проектирование:
     • выбор проектных решений по аспектам разработки ИС;
     • описание реальных компонент ИС;
     • оформление и утверждение технического проекта (ТП).
   • 2.2. Детальное проектирование:
     • выбор или разработка математических методов или алгоритмов программ;
     • корректировка структур БД;
     • создание документации на доставку и установку программных продуктов;
     • выбор комплекса технических средств с документацией на её установку.
   • 2.3. Разработка техно-рабочего проекта ИС (ТРП).
   • 2.4. Разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.
3. Разработка ИС
   • получение и установка технических и программных средств;
   • тестирование и доводка программного комплекса;
   • разработка инструкций по эксплуатации программно-технических средств.
4. Ввод ИС в эксплуатацию
   • ввод технических средств;
   • ввод программных средств;
   • обучение и сертификация персонала;
   • опытная эксплуатация;
   • сдача и подписание актов приёмки-сдачи работ.
5. Эксплуатация ИС
   • повседневная эксплуатация;
   • общее сопровождение всего проекта.

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трёх группах процессов:

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

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

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего, процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.

В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ).

ЖЦИС - это период создания и использования ИС, начиная с момента возникновения потребности в ИС и заканчивая моментом полного её выхода из эксплуатации.

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

Традиционно выделяются следующие основные этапы ЖЦ ПО:

анализ требований;

проектирование;

кодирование (программирование);

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

эксплуатация и сопровождение.

Стадии жизненного цикла информационной системы

Предпроектное обследование

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

1.2. Анализ материалов и разработка документации; обязательно даётся технико-экономическое обоснование с техническим заданием на проектирование ИС .

Проектирование

• 2.1. Предварительное проектирование:

  • выбор проектных решений по аспектам разработки ИС;

    описание реальных компонент ИС;

    оформление и утверждение технического проекта (ТП).

2.2. Детальное проектирование:

• выбор или разработка математических методов или алгоритмов программ;

  корректировка структур БД;

  создание документации на доставку и установку программных продуктов;

  выбор комплекса технических средств с документацией на её установку.

2.3. Разработка техно-рабочего проекта ИС (ТРП).

2.4. Разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.

Разработка ИС

• получение и установка технических и программных средств;

  тестирование и доводка программного комплекса;

  разработка инструкций по эксплуатации программно-технических средств.

Ввод ИС в эксплуатацию

• ввод технических средств;

  ввод программных средств;

  обучение и сертификация персонала;

  опытная эксплуатация;

  сдача и подписание актов приёмки-сдачи работ.

Эксплуатация ИС

• повседневная эксплуатация;

  общее сопровождение всего проекта.

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5 ] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - InternationalElectrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трёх группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего, процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.