Принципы разработки информационных систем

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

Периодически появляются различные издания принципов, принадлежащие различным коллективам. Исторически первыми в СССР появились принципы проектирования АСУ, предложенные академиком В.М.Глушковым:

1) Принцип системности заключается в повсеместном применении системного подхода:

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

- выявление структурных элементов и взаимосвязей между ними:

- макроанализ: выделяются функции и связи элемента,

- микроанализ: выделяется и изучается структура элемента;

- формирование многоуровневой иерархии: система, подсистемы, ….

1) Принцип непрерывного развития предполагает постоянное изменение и наращивание возможностей ИС. Несомненно, что высокая адаптивность ИС остается актуальной и сейчас.

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

1) Принцип стандартизации и унификации предусматривает широкое использование стандартных решений и компонентов.

1) Принцип эффективности - создание АСУ должно быть экономически выгодным.

Кроме перечисленных общих принципов были предложены более детальные частные принципы:

1) Принцип декомпозиции - разделение системы на части для последующего анализа и реализации.

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

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

1) Принцип автоматизации информационных потоков и документооборота предусматривает использование технических средств на всех этапах создания и обработки документов.

1) Принцип автоматизации проектирования предполагал использование информационных технологий для создания, ведения и доступа к проектной документации, автоматическое генерирование заготовок проектных документов, структур данных, программ по проектным описаниям. Сейчас эта идея реализована в CASE - средствах.

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

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

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

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

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

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

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

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

Лекция 3. Модели ЖЦ

Понятие жизненного цикла информационных систем. Стандарты организации ЖЦ.

Технология создания крупных информационных систем (далее - ИС) связана с понятием жизненного цикла (ЖЦ).

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

Стадии жизненного цикла ИС рассматриваются в стандартах на разработку ИС. Из большого числа таких стандартов выделим международный стандарт ISO/IEC12207 и отечественную группу стандартов ГОСТ 34, поскольку именно они широко используются на практике.

ISO (Международная организация стандартизации) и IEC (международная электротехническая комиссия) образуют специализированную систему мировой стандартизации. Национальные органы, являющиеся членами ISO или IEC, участвуют в разработке международных стандартов при помощи технических комитетов, образованных соответствующими организациями, чтобы рассматривать отдельные разделы технической деятельности. В области информационной технологии ISO и IEC образовали объединенный технический комитет ISO /IEC JTC1. Проекты международных стандартов, принятые объединенным техническим комитетом, рассылаются национальным органам с целью их принятия. Публикация в качестве международного стандарта требует подтверждения от не менее, чем 75% национальных органов, принимавших участие в принятии решения.

Международный стандарт ISO/IEC 12207 был подготовлен объединенным техническим комитетом ISO/IEC JTC1,"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

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

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

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

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

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

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

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

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

К настоящему времени наибольшее распространение получили следующие две основные модели проектирования систем:

l каскадная модель (70-80 г.г.);

l итерационная модель (80-85г.г.)

l спиральная модель (86-90 г.г.).

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

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

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

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

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

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

Рис. 3.2. Итерационный процесс разработки ПО

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ

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

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

Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

Среди наиболее известных стандартов можно выделить следующие:

· ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

· ISO/ IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

· Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

· Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

· Microsoft Solution Framework (MSF) сходна с RUP, также включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

1.1.