1. Жизненный цикл ИС и его структура. 2

1.1 Стадии жизненного цикла ИС.. 3

1.2 Стандарты жизненного цикла ИС.. 4

2. Модели жизненного цикла. 6

2.1 Типы моделей жизненного цикла ИС.. 6

2.2 Достоинства и недостатки моделей жизненного цикла ИС.. 8

3. Процессы жизненного цикла ИС.............................................................. 11

3.1 Основные процессы жизненного цикла. 11

3.2 Вспомогательные процессы жизненного цикла. 13

3.3 Организационные процессы.. 14

Список использованной литературы.. 16

Жизненный цикл информационной системы - период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации.

Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

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

1.1 Стадии жизненного цикла ИС

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

На стадии уточнения проводится анализ прикладной области, разрабатывается архитектурная основа информационной системы.

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

В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных факторов риска в проекте.

3) Стадия конструирования

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

4) Стадия передачи в эксплуатацию

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

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

1.2 Стандарты жизненного цикла ИС

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

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

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

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission)1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

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

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

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последоват ельно дорабатываемых прототипов.

2. Модели жизненного цикла

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

Модель ЖЦ ИС включает в себя:

результаты выполнения работ на каждой стадии;

ключевые события - точки завершения работ и принятия решений.

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

2.1 Типы моделей жизненного цикла ИС

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

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

Поэтапная модель с промежуточным контролем (рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

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

Рис. 2.1. Каскадная модель ЖЦ ИС

Рис. 2.2. Поэтапная модель с промежуточным контролем

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

2.2 Достоинства и недостатки моделей жизненного цикла ИС

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

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

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

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

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

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

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

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

Привычка - многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.

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

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

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

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

3.1 Основные процессы жизненного цикла

Приобретение (действия и задачи заказчика, приобретающего ИС)

Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)

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

Эксплуатация (действия и задачи оператора - организации, эксплуатирующей систему)

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

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

Разработка

Разработка информационной системы включает в себя все работы по созданию информационного программного обеспечения и его компонентов в соответствии с заданными требованиями. Разработка информационного программного обеспечения также включает:

оформление проектной и эксплуатационной документации;

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

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

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

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

Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся:

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

обеспечение пользователей эксплуатационной документацией;

обучение персонала.

Основные эксплуатационные работы включают:

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

локализацию проблем и устранение причин их возникновения;

модификацию программного обеспечения;

подготовку предложений по совершенствованию системы;

развитие и модернизацию системы.

Сопровождение

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

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

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

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

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

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

3.2 Вспомогательные процессы жизненного цикла

Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)

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

Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

Аудит (определение соответствия требованиям, планам и условиям договора)

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

3.3 Организационные процессы

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

Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)

Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает:

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

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

разработку методов и средств испытаний созданного программного обеспечения;

1. Избачков С.Ю., Петров В.Н. Информационные системы–СПб.: Питер, 2008. – 655 с

2. http://ru.wikipedia.org

3. http://www.intuit.ru

Лабораторная работа №1

Выделение жизненных циклов проектирования компьютерных систем

Цель работы : ознакомиться с моделями жизненного цикла информационных систем, определить достоинства и недостатки моделей, выбрать модель построения информационной системы индивидуального проектного задания и программные средства, составить план реализации индивидуального проектного задания.

Краткие теоретические сведения.

Жизненный цикл информационной системы

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

Жизненный цикл ИС –это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.

Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):

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

· ISO/IEC 12207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:

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

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

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

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

o ISO/IEC TR 15271:1998 – руководство по применению ISO/IEC 12207;

o ISO/IEC TR 16326:1999 – руководство по управлению проектами при использовании ISO/IEC 12207.

· ISO/IEC 15288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т.д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества – среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15288.

· Rational Unified Process (RUP) – концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне – подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом – его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).

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

· Extreme Programming (XP). Экстремальное программирование – это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990-ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).

Модели ЖЦ ИС.

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

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

Выбор модели жизненного цикла зависит от специфики, масштаба, сложности проекта и набора условий, в которых АИС создается и функционирует.

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

I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.

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

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

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

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

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

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

Последний этап - сдача готового проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

ЛЕКЦИЯ 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-диаграмм в проектные решения АСУП.

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

УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ФИНАНСОВАЯ АКАДЕМИЯ

ПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ»

Кафедра «Информационные технологии»

РЕФЕРАТ

Тема: «Роль экономиста в создании и эксплуатации

Выполнила:

студентка группы У5-3

Научный руководитель:

профессор кафедры «Информационные технологии»

д. э.н., профессор

Москва 2007

Введение.. 3

1. Стадии и этапы разработки информационных систем... 4

1.1. Жизненный цикл информационных систем.. 4

1.2. CASE-технологии проектирования ИС.. 8

1.3. Модели жизненного цикла, применяемые в CASE-технологиях. 8

1.4. Принципы создания и функционирования экономических информационных систем 12

1.5. Требования стандартов по разработке информационных систем.. 12

2. Роль экономиста на различных фазах жизненного цикла информационной системы бухгалтерского учета.. 16

2.1. Предпроектная стадия жизненного цикла. 16

2.2. Проектирование и разработка информационной системы.. 19

2.3. Внедрение информационной системы.. 19

Заключение.. 20

Литература.. 20

Введение

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

Важное место среди профессионально-ориентированных ИС играют информационные системы бухгалтерского учета (ИС БУ). Примером такой системы, занимающей лидирующее положение в России и ряде зарубежных стран, является программный продукт «1С: Бухгалтерия 8.0», входящей в систему программ «1С: Предприятие 8.0».

Система «1С: Бухгалтерия 8.0» предназначена для автоматизации бухгалтерского и налогового учета, включая подготовку обязательной (регламентированной) отчетности, в организациях, осуществляющих любые виды коммерческой деятельности: оптовую и розничную торговлю, оказание услуг, производство и т. д. Бухгалтерский и налоговый учет ведется в соответствии с действующим законодательством Российской Федерации .

Структурно система «1С: Бухгалтерия 8.0» включает технологическую платформу «1С: Предприятие 8.0» и конфигурацию «Бухгалтерия предприятия». Конфигурация, являясь прикладным решением, определяет правила ведения учета; она должна быть настроена на структуру, профиль и особенности конкретного предприятия. И в этом, прежде всего, роль экономиста в создании и внедрении ИС БУ, хотя, безусловно, проектирование и разработка ИС БУ, осуществляемая фирмой 1С, не может быть реализована без тесного взаимодействия IT-специалистов с профессиональными экономистами, менеджерами, бухгалтерами, аудиторами, экспертами различных управленческих уровней, прежде всего высших и средних.

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

Для уточнения, более полного раскрытия роли экономистов в создании и эксплуатации ИС БУ в коммерческой организации рассмотрим стадии и этапы разработки информационных систем, а затем выполним оценку взаимодействия IT-специалистов и профессионалов-экономистов на различных фазах жизненного цикла ИС БУ.

1. Стадии и этапы разработки информационных систем

1.1. Жизненный цикл информационных систем

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

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

Требования к ИС строго формализуются и фиксируются в техническом задании . Существенное внимание уделяется планированию работ, организации труда в коллективе специалистов, число которых может достигать сотен и тысяч человек, управлению работами и контролю за их выполнением, а также соблюдением заданных программных характеристик. Внедрение в эксплуатацию предваряется проведением многоступенчатых испытаний в специально сформированных или реальных условиях. Обязательной является фаза сопровождения и связанная с этим необходимость подготовки качественной программной документации, тиражирования и передачи ИС в другие эксплуатирующие организации. Общее время жизни ИС может достигать десяти и более лет, из которых 70 – 90% может приходиться на фазы эксплуатации и сопровождения. Длительность эксплуатации может вызвать необходимость модернизации ИС и, соответственно, возврата к ранее пройденным фазам.

В начале 80-х годов прошлого века известный отечественный ученый предложил следующую схему жизненного цикла ИС (рис. 1.1).

Рис. 1.1. Схема жизненного цикла ИС по

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

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

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

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

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

Схема жизненного цикла ИС (программного изделия как большого комплекса программ вместе с программной документацией), предложенная, опиралась на принятые в нашей стране, начиная с 1977 года, Государственные стандарты Единой системы программной документации (ГОСТ ЕСПД). Она послужила развитием каскадной модели жизненного цикла , используемой на западе в 70-е – 85-е годы прошлого века при разработке сложных ИС (рис. 1.2). Суть каскадной модели: вся разработка разбивается на несколько этапов. Переход на следующий этап происходит только после полного завершения работ на предыдущем этапе.

Каскадный подход имеет ряд положительных сторон:

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

Рис. 1.2. Схема каскадного подхода к построению ИС

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

Устраняя недостатки каскадной модели, в 80-е годы прошлого века на западе была предложена «водопадная » модель (waterfall model) разработки ИС, отражающая реальные процессы (рис. 1.3).

В 86-е – 90-е годы прошлого века получила развитие спиральная модель жизненного цикла ИС (рис. 1.4), в которой основной упор сделан на начальные этапы – анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.

Рис. 1.3. «Водопадная» модель разработки ИС

Рис. 1.4. Спиральная модель жизненного цикла ИС

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

Вторым названием спиральной модели является «продолжающееся проектирование». Позднее, когда в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы, она получила название «быстрого прототипирования» (rapid prototyping approach или fast-track).

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

1.2. CASE-технологии проектирования ИС

Возрастающая сложность современных ИС и повышение требовательности к ним обусловливают применение эффективных технологий создания и сопровождения ИС в течение всего жизненного цикла. Такие технологии, базирующиеся на методологиях подготовки ИС и соответствующих комплексах интегрированных инструментальных средств, а также ориентированные на поддержку полного жизненного цикла ИС или ее основных этапов, получили название CASE-технологий и CASE-средств. Для успешной реализации проекта ИС должны быть построены полные и непротиворечивые функциональные и информационные модели системы управления. Накопленный опыт проектирования указанных моделей показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако во многих случаях проектирование ИС выполняется в основном на интуитивном уровне с применением неформальных методов, основанных на искусстве, практическом опыте и экспертных оценках. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение ИС. От перечисленных недостатков в наибольшей степени свободны подходы, основанные на программно-технических средствах специального класса – CASE-средствах, реализующих CASE-технологии создания и сопровождения ИС.

Под термином CASE (Computer Aided Software Engineering) понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных , генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки ИС.

1.3. Модели жизненного цикла, применяемые в CASE-технологиях

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

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

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

· применения операций отслеживания хода выполнения действий с контрольными этапами.

Опираясь на результаты разработки крупных IT-проектов и проблемы, которые при этом возникали, М. Кантор поддерживает вывод, сделанный Фредериком Бруксом в книге «Мифический человеко-месяц» (1995 г.) – «в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться», так как требования к таким системам «характеризуются высокой динамикой корректировки и уточнения, невозможностью четкого и однозначного определения до начала работ по реализации».

Рис. 1.5. Каскадная модель жизненного цикла по М. Кантору

Спиральная эволюционная модель, в развитие которой внесли вклад Мартин Фаулер (2004 г.), Скотт Амблер (2004 г.), определяет эволюционную модель как сочетание итеративного и инкрементального подходов – последовательное выполнение итераций и наращивание функциональных возможностей ИС (рис. 1.6).

Скотт Амблер предлагает использовать несколько уровней жизненного цикла, определяемых соответствующим содержанием работ (рис.1.7).

1. Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем.

2. Жизненный цикл программной системы – включает разработку, развертывание, поддержку и сопровождение.

3. Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента.

4. Жизненный цикл организации/бизнеса – охватывает всю деятельность организации в целом.

Рис. 1.6. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла

Рис.1.7. Содержание четырех категорий жизненного цикла по С. Амблеру

Барри Боэм (1988 г.) связал спиральную модель с рисками , влияющими на организацию жизненного цикла. Он выделил 10 наиболее распространенных (по приоритетам) рисков:

1) дефицит специалистов;

2) нереалистичные сроки и бюджет;

3) реализация несоответствующей функциональности;

4) разработка неправильного пользовательского интерфейса;

5) «золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей;

6) непрекращающийся поток изменений;

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

8) недостатки в работах, выполняемых внешними по отношению к проекту ресурсами;

9) недостаточная производительность получаемой системы;

10) «разрыв» в квалификации специалистов разных областей знаний.

Большая часть рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

Модель жизненного цикла Б. Боэма представлена на рис. 1.8.

Рис. 1.8. Оригинальная спиральная модель жизненного цикла разработки ИС по Б. Боэму

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

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

Выделяют несколько принципов создания и функционирования ЭИС.

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

2. Принцип развития. Предопределяет ЭИС как систему, способную к развитию и совершенствованию при использовании новейших технологий процесса обработки данных.

3. Принцип совместимости. ЭИС строится как открытая система, ориентированная на максимальное использование стандартов программного, технического и иного обеспечения.

4. Принцип непосредственного участия. В процессе обследования и создания ЭИС принимают непосредственное участие работники предприятия (фирмы).

5. Принцип безопасности. Обеспечивается безопасность всех информационных процессов, сохранность и целостность коммерческой информации, циркулируемой в ЭИС.

6. Принцип эффективности. Достижение рационального соотношения между затратами на создание ЭИС и результатами, полученными в процессе ее эксплуатации.

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

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

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

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

1) Модульность:

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

2) Ответственность:

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

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

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

Поставка (5.2). Процесс определяет работы и задачи поставщика:

инициирование (подготовка); подготовка предложения (подготовка ответа); разработка контракта (подготовка договора); планирование; выполнение и контроль; проверка и оценка; поставка и завершение (поставка и закрытие договора).

Разработка (5.3). Процесс определяет работы и задачи разработчика:

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

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

Эксплуатация (5.4). Процесс определяет работы и задачи оператора службы поддержки:

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

Сопровождение (5.5). Процесс определяет работы и задачи, проводимые специалистами службы сопровождения:

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

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

Таким образом, в настоящее время регламентирован процесс разработки ИС: определены фазы жизненного цикла, стадии и этапы разработки ИС, предусмотрена совместная деятельность IT-специалистов – разработчиков ИС и профессионалов-экономистов.

2. Роль экономиста на различных фазах жизненного цикла информационной системы бухгалтерского учета

2.1. Предпроектная стадия жизненного цикла

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

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

Предпроектная стадия предшествует работам по созданию ИС.

Рис. 2.1. Роль и место специалистов-экономистов на стадиях жизненного цикла ИС

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

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

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

От тщательности действий на предпроектной стадии при разработке ТЗ, согласованности исполнителей – привлеченных IT-специалистов, которым поручена разработка ИС, и экономистов, достоверности полученных оценок, обоснованности решений, представленных утверждение руководителю, во многом зависит будущая эффективность применения ИС БУ. Действия экономистов здесь оцениваются достаточно высоко: управленцы высшего звена – (++), среднего звена – (+++), низшего звена – (+), консультанты-эксперты – (+++).

2.2. Проектирование и разработка информационной системы

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

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

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

Высшая оценка на стадии проектирования иразработки ИС у экономистов среднего звена – (+++), далее идут экономисты низшего звена – (++), затем высшего – (+).

Оценка консультантов-экспертов незначительна – (+- –).

2.3. Внедрение информационной системы

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

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

На стадии внедрения ИС особенно велика роль экономистов. Деятельность специалистов высшего звена оценивается в ходе приемо-сдаточных испытаний высшим баллом – (++++), в ходе опытной и промышленной эксплуатации – (+). Специалисты среднего звена и консультанты-эксперты в ходе приемо-сдаточных испытаний имеют оценку (+++), специалисты низшего звена – (+). На этапах опытной и промышленной эксплуатации выше роль специалистов низшего звена – (+++); оценка специалистов среднего звена – (++); роль экспертов-консультантов незначительна – (+-–).

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

Заключение

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

Экономисты высшего звена управления играют решающую роль на ключевых этапах – принятии решения о создании ИС и приемке ее в эксплуатацию.

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

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

Литература

1. Экономическая информатика: Учебник / Под ред. . -2-е изд. –М.: Финансы и статистика, 2004. – 592 с.

2. Воройский. Энциклопедический систематизированный словарь-справочник. (Введение в современные информационные и телекоммуникационные технологии в терминах и фактах). - М.: 2007.

3. Липаев программного обеспечения. –М.: Финансы и статистика, 19 с.

4. Лобанова Т. Жизненный цикл информационных систем – выберем стандарты, выстроим методологию. – В журн. Оборудование, сентябрь, 2005. с.

5. Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. –М.: 2005. sorlik.

6. Харитонов лекций. –М.: 2006 – 2007.

7. Чистов к дисциплине «Информационные системы в экономике». –М.: 2006.

ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electro technical Commission - Международная комиссия по

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

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

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

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

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

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

1. Разработка

Разработка информационной системы включает в себя все работы по разработке информационного программного обеспечения и его компонентов в соответствии с заданными требованиями. Разработка информационного программного обеспечения также включает:

1. оформление проектной и эксплуатационной документации;

2. подготовку материалов, необходимых для проведения тестирования тайных программных продуктов;

3. разработку материалов, необходимых для организации обучения персонала.

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

2. Эксплуатация

Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся:

1. конфигурирование базы данных и рабочих мест пользователей;

2. обеспечение пользователей эксплуатационной документацией;

3. обучение персонала.

Основные эксплуатационные работы включают;

1. непосредственно эксплуатацию;

2. локализацию проблем и устранение причин их возникновения;

3. модификацию программного обеспечения;

4. подготовку предложений по совершенствованию системы;

5. развитие и модернизацию системы.

3. Сопровождение

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

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

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

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

1. задачная модель;

2. каскадная модель (или системная) (70-85 г.г.);

3. спиральная модель (настоящее время).

Задачная модель

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

Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

небольшую команду программистов (от 2 до 10 человек);

короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

1. фаза определения требований и анализа;

2. фаза проектирования;

3. фаза реализации;

4. фаза внедрения.

Лекция 6. Классификация информационных систем

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

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

1. одиночные;

2. групповые;

3. корпоративные.

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создайся с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.

Групповые информационные системы ориентированы на коллективное использова­ние информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (Называемые также SQL-серверами) для рабочих групп. Существует доволь­но большое количество различных SQL-серверов, как коммерческих, так и свобод­но распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать тер­риториально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура кли­ент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

1. системы обработки транзакций;

2. системы принятия решений;

3. информационно-справочные системы;

4. офисные информационные системы.

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

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

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

Класс офисных информационных систем нацелен на перевод бумажных докумен­тов в электронный вид, автоматизацию делопроизводства и управление докумен­тооборотом.

Классификация по способу организации

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

1. системы на основе архитектуры файл-сервер;

2. системы на основе архитектуры клиент-сервер;

3. системы на основе многоуровневой архитектуры;

4. системы на основе Интернет/интранет - технологий.

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

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

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

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

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

2. средний уровень представляет собой сервер приложений;

3. верхний уровень представляет собой удаленный специализированный сервер базы данных.

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

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

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

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

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

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

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