Жизненный цикл разработки автоматизированных информационных систем и его этапы

Обеспечение качества проекта связано с проблемами вери­фикации, проверки и тестирования компонентов информацион­ной системы.

Верификация — это процесс определения соответствия теку­щего состояния разработки, достигнутого на данном этапе, тре­бованиям данного этапа.

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

Для поддержки практического применения стандарта ISO/ IEC 12207 разработан ряд технологических документов: Руково­дство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology — Guide for ISO/IEC 12207) и Руководство по приме­нению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering — Guide for the application of ISO/ IEC 12207 to project management).

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). В разработке стандарта участвовали специалисты различных областей. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академи­ческих организациях. Стандарт применим для широкого класса систем, но его основное назначение — поддержка создания ком­пьютеризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру жиз­ненного цикла нужно включать следующие группы процессов.

1.      Договорные процессы:

•          приобретение (внутренние решения или решения внеш­него поставщика);

•          поставка (внутренние решения или решения внешнего поставщика).

2.      Процессы предприятия:

•          управление окружающей средой предприятия;

•          инвестиционное управление;

•          управление жизненным циклом информационной сис­темы;

•          управление ресурсами;

•          управление качеством.

3.      Проектные процессы:

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

•          оценка проекта;

•          контроль проекта;

•          управление рисками;

•          управление конфигурацией;

•          управление информационными потоками;

•          принятие решений.

4.      Технические процессы:

•          определение требований;

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

•          разработка архитектуры;

•          внедрение;

•          интеграция;

•          верификация;

•          переход;

•          аттестация;

•          эксплуатация;

•          сопровождение;

•          утилизация.

5.      Специальные процессы:

•          определение и установка взаимосвязей исходя из задач и целей.

Перечень стадий создания систем и основные результаты, которые должны быть достигнуты к моменту их завершения, в соответствии со стандартом ISO/IEC 15288, приведены ниже в табл.2.

Таблица 2. В 1970-х гг. корпорация IBM предложила методологию BSP (Business System Planning — Методология организационного планирования).

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

Модели жизненного цикла АИС

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

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

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

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

Итерационная модель.

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

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

Недостатки итерационной модели:

•          время жизни каждого из этапов растягивается на весь пе­риод разработки;

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

•          запутанность архитектуры;

•          трудность в использовании проектной документации (вы­зывает на стадиях внедрения и эксплуатации необходи­мость перепроектирования всей системы).

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

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

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

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

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

Рис. 1. Каскадная схема разработки

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

Рис.2. Реальный процесс разработки ПО по каскадной схеме

Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.

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

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

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

Достоинства:

1. Упрощает внесение изменений при необходимости или требованию заказчика;

2. Отдельные элементы ИС интегрируются в единое целое постоянно, т.к. начинается с меньшего количества элементов;

3. Уменьшение уровня риска [схема];

4. Обеспечивает большую гибкость в управлении проектом, поскольку дает возможность вносить тактические изменения в разрабатываемое изделие;

5. Упрощает повторное использование компонентов. Это происходит из-за того, что гораздо проще выделить общие части проекта, когда они уже частично разработаны;

6. позволяет получить более надежную и устойчивую систему. По мере развития системы мы исправляем ошибки и вносим изменения;

7. Позволяет совершенствовать процесс разработки.

Недостатки:

1.       Основная проблема определения момента перехода на следующий этап.

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

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