Модели жизненного цикла автоматизированных информационных систем

Департаментобразования города Москвы
ГосударственноеБюджетноеОбразовательное Учреждение
среднегопрофессионального образования
Политехническийколледж №8
именидважды Героя Советского Союза И.Ф. Павлова
КУРСОВАЯРАБОТА
Предмет:Разработка и эксплуатация автоматизированных информационных систем
Тема:Модели жизненного цикла автоматизированных информационных систем
ИСПОЛНИТЕЛЬ:Антохин Игорь Николаевич
Москва,2010г.

Содержание
Введение
Глава 1. Моделижизненного цикла автоматизированных информационных систем
1.1 Жизненный циклАИС
1.2 Процессыжизненного цикла АИС
1.3 Основныепроцессы жизненного цикла АИС
1.4 Вспомогательныепроцессы жизненного цикла АИС
1.5 Организационныепроцессы жизненного цикла АИС
1.6 Моделижизненного цикла автоматизированных информационных систем
1.7 Каскадная модель
1.8 Спиральнаямодель
Глава 2. СASE-технологии
2.1 Основныеметодологии проектирования автоматизированных систем на основе CASE-технологий
2.2 Фазы жизненногоцикла программного обеспечения. Фаза анализа и планирования требований
2.3 Фазапроектирования
2.4 Фаза построения
2.5 Фаза внедрения
Глава 3. Моделижизненного цикла программного продукта
3.1 Определениемодели жизненного цикла АИС
3.2 Каскадная модель
3.3 V-образная модель
3.4 Модельпрототипирования
3.5 Модель быстройразработки приложений (RAD-модель)
3.6 Многопроходнаямодель
3.7 Спиральнаямодель
Заключение
Списокиспользованной литературы

Введение
Современноеобщество невозможно представить без компьютера. Они настолько широко и глубоко внедрилисьв нашу жизнь, что очень трудно назвать какую-либо сферу деятельности человека,где они не использовались. В связи с этим серьезные требования предъявляются ик аппаратной части современных компьютеров, и к используемому программномуобеспечению. В основном именно программное обеспечение, или, иными словами,программные продукты, обеспечивают возможность широкого использованиякомпьютеров. Стоит нам переустановить программное обеспечение компьютера илидобавить какой-либо новый программный продукт, и мы сможем решать на этомкомпьютеры совершенно новые задачи. Следовательно, используемые программныепродукты должны соответствовать определенным критериям, обеспечивающимнадежность работы компьютера и удобство работы пользователя.
Вданной курсовой работе рассматриваются модели жизненного циклаавтоматизированных информационных систем и программного продукта. Работасостоит из трех глав.
Впервой главе рассказывается о моделях жизненного цикла автоматизированныхинформационных системах.
Жизненныйцикл автоматизированных информационных систем — это непрерывный процесс, которыйначинается с момента принятия решения о необходимости создания ИС изаканчивается в момент ее полного изъятия из эксплуатации.
Модельжизненного цикла — структура, определяющая последовательность выполнения ивзаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ.
Наибольшеераспространение получили две основные модели ЖЦ:
· каскаднаямодель (70-85 гг.);
· спиральнаямодель (86-90 гг.).
Вовторой главе речь идет о CASE-технологиях. CASE-технология — технология,базирующаяся на методологиях подготовки информационных систем и соответствующихкомплексах интегрированных инструментальных средств, а также ориентированная наподдержку полного жизненного цикла автоматизированной системы или его основныхэтапов.
Жизненныйцикл программного обеспечения в соответствии с методологией RAD состоит изчетырех фаз: анализа и планирования требований; проектирования; построения;внедрения.
Втретьей главе — модели жизненного цикла программного продукта.
Подмоделью жизненного цикла разработки программного продукта понимается структура,определяющая последовательность выполнения и взаимосвязи процессов, действий изадач, выполняемых на протяжении жизненного цикла разработки программногопродукта. Наибольшее распространение получили следующие модели жизненного цикларазработки программного продукта: каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модельпрототипирования (prototype model); модель быстрой разработкиприложений, или RAD-модель (RAD-rapid application development model); многопроходнаямодель (incremental model); спиральная модель (spiral model).

ГЛАВА1. Модели жизненного цикла автоматизированных информационных систем
1.1Жизненный цикл АИС
Жизненныйцикл автоматизированных информационных систем — это непрерывный процесс, которыйначинается с момента принятия решения о необходимости создания ИС изаканчивается в момент ее полного изъятия из эксплуатации (рис.1).
/>

Рис.1Структурная схема терминов
1.2Процессы жизненного цикла АИС
Жизненныйцикл — одно из базовых понятий методологии проектирования информационных систем. Этонепрерывный процесс, который начинается с момента принятия решения онеобходимости создания информационной системы и заканчивается в момент ееполного изъятия из эксплуатации.
Основнымнормативным документом, регламентирующим жизненный цикл, является международныйстандарт ISO/IEC 12207 (ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — InternationalElectrotechnical Commission — Международная комиссия по электротехнике). Онопределяет структуру жизненного цикла, содержащую процессы, действия и задачи,которые должны быть выполнены во время создания информационной системы.
Структуражизненного цикла по стандарту ISO/IEC 12207 базируется на трех группахпроцессов: основные, вспомогательные, организационные.
1.2.1.Основные процессы жизненного цикла АИС
Основныепроцессы включают в себя набор определенных действий и связанных с ними задач,которые должны быть выполнены в течение жизненного цикла программного продукта.
Косновным относятся процессы приобретения, постаки, разработки, эксплуатации исопровождения.
Процессприобретения охватывает действия заказчика по приобретению ПП. К этим действиямотносятся:
1)        Инициированиеприобретения включает в себя много задач, в том числе определение заказчикомсвоих потребностей в приобретении, разработки или усовершенствование системыПП.
2)        Подготовказаявочных предложений подразумевает разработку и составление предложений,которые должны содержать: требования к разрабатываемой или покупаемой системе;перечень необходимых ПП; условия и соглашения; технические ограничения.
3)        Подготовкаи корректировка договора включает в себя следующие задачи: выбор поставщикомкритерия оценки предложений; выбор конкретного поставщика на основе анализапредложений; подготовка и заключение договора с поставщиком; внесение изменений(при необходимости) в договор в процессе его выполнения.
4)        Надзорза деятельностью поставщика осуществляется в соответствии с действиями,предусмотренными в процессе совместной оценки аудита.
5)        Приемкаи завершение работ
Впроцессе приемки подготавливаются и выполняются необходимые тесты. Завершениеработ по договору осуществляется в случае удовлетворения всем условиям приемки.
Процесспоставки охватывает действия и задачи поставщика при снабжении заказчика ПП илиуслугой.
К этимдействиям относятся:
1)        Инициированиепоставки заключается в рассмотрении поставщиком заявочных предложений ипринятия решения;
2)        Подготовкаответа на заявочные предложения выполняются в соответствии с принятымирешениями;
3)        Подготовкадоговора осуществляется после выбора заказчиком конкретного поставщика;
4)        Планированиевыполняется после заключения договора и включает в селя следующие задачи: принятиерешения поставщиком относительно выполнения работ своими силами или сподключением субподрядчика; разработку поставщиком плана управления проектом,содержащего организационную структуру проекта, разграничение ответственности,технические требования к среде разработки, управление субподрядчиками.
Субподрядчик– организация, индивидуум или корпорация, заключившая договор с поставщиком наисполнение части работ, которые поставщик должен выполнить по договору сзаказчиком.
5)        Выполнениеи контроль
6)        Проверкаи оценка
7)        Поставкаи завершение работ выполняется в соответствии с оговоренными в процессеинициирования действиями по приемки и завершении работ.
Процессразработки охватывает действия и задачи разработчика и предусматриваетследующие основные направления работ:
1)        СозданиеПП и его компонентов с заданными требованиями, включая оформление проектной иэксплуатационной документации
2)        Подготовкуматериалов, необходимых для проверки работоспособности и качества ПП
3)        Подготовкуматериалов, необходимых для организации обучения персонала и т.д.
Процессэксплуатации охватывает действия и задачи оператора – организации, занимающейсяэксплуатацией разработанного ПП. К этим действиям относятся: подготовительнаяработа, эксплуатационное тестирование, эксплуатация системы, поддержкапользователей заключается в оказании помощи и консультациях при обнаруженииошибок в процессе эксплуатации ПП.
Процесссопровождения. Данный процесс активизируется при изменениях (модернизации) ПП исоответствующей документации, вызванных возникшими проблемами.
Основнойцелью этих процессов является создание надежного, полностью удовлетворяющеготребованиям заказчика ПП в установленные договором сроки.
1.2.2Вспомогательные процессы жизненного цикла АИС
Основнойцелью этих процессов является создание надежного, полностью удовлетворяющеготребованиям заказчика ПП в установленные договором сроки. К вспомогательнымотносятся процессы документирования, управления конфигурацией, обеспечениякачества, верификации, аттестации, совместной оценки, аудита, разрешенияпроблем.
Процессдокументирования предусматривает формализованное описание информации, созданнойв течении ЖЦ ПП.
Этотпроцесс включает в себя:
1)        Подготовительнуюработу, которая требуется для определения и согласования необходимого перечнядокументов и документируемых процедур;
2)        Проектированиеи разработку документации, которые выполняются в процессе работы над ПП изавершается одновременно с завершением его ЖЦ;
3)        Выпускдокументации, который осуществляется по мере ее готовности;
4)        Сопровождениевключает в себя действия по корректировки и обновлению документации в процессеЖЦ ПП.
Процессуправления конфигурацией предполагает применение административных и техническихпроцедур на всем протяжении ЖЦ ПП.
Согласностандарту IEEE-90 под конфигурациейПП понимается совокупность его функциональных и физических характеристик,установленных в технической документации и реализованных в ПП.
Этотпроцесс включает в себя:
1)        Подготовительнуюработу, которая заключается в планировании управления конфигурацией;
2)        Идентификациюконфигурации — устанавливает правила, с помощью которых можно однозначноидентифицировать и различать компоненты ПП и их версии. Кроме того каждомукомпоненту и его версиям соответствует однозначно обозначаемый комплект документации;
3)        Контрольконфигурации – предназначен для систематической оценки предполагаемыхмодификаций ПП и координированной их реализации с учетом эффективности каждоймодификации и затрат на ее выполнение;
4)        Учетсостояния конфигурации — представляет собой регистрацию состояния компонентовПП, подготовку отчетов обо всех реализованных и отвергнутых модификациях версийкомпонентов ПП;
5)        Оценкуконфигурации – заключается в оценки функциональной полноты компонентов ПП;
6)        Управлениевыпуском и поставкой включает в себя изготовление эталонных копий программ идокументации, их хранение и поставку пользователям в соответствии с порядком,принятом в организации.
Процессобеспечения качества обеспечивает соответствующую гарантию того, что ПП ипроцессы его ЖЦ ПП соответствуют заданным требованиям и утвержденным планам.
Дляполучения достоверных оценок создаваемого ПП процесс обеспечения его качествадолжен происходить независимо от субъектов, непосредственно связанных сразработкой ПП.
Процессверификации состоит в доказательстве, того, что ПП, являющийся результатомнекоторого действия полностью удовлетворяет требования или условия, зависящихот предшествующих действий.
Верификацияможет проводиться как самим исполнителем, так и другим специалистом даннойорганизации, а так же специалистом сторонней организации. Верификация в узкомсмысле означает формальное доказательство правильности ПП. Данный процесс можетвключать в себя анализ, оценку и тестирование.
Процессаттестации предусматривает определение полноты соответствия заданных требованийк создаваемой системе или ПП.
Податтестацией обычно понимают подтверждение и оценку достоверности проведенноготестирования ПП. Аттестация должна гарантировать полное соответствие, а такжевозможность его безопасного и надежного применения пользователем.
Процесссовместной оценки предназначен для оценки состояния работ по проекту и ПП. Онзаключается в основном в контроле за планированием и управлением ресурсами,персоналом, аппаратурой и инструментальными средствами проекта.
Процессаудита представляет собой определение соответствия требованиям, планам иусловиям договора как хода выполнения работ по созданию ПП, так и самогопродукта.
Аудитслужит для установления соответствия реальных работ и отчетов, поэтому аудиторы(ревизоры) не должны иметь прямой зависимости от разработчиков ПП.
Процессразрешения проблем предусматривает анализ и решение проблем, обнаруженных входе разработки, эксплуатации и других процессов, независимо от их проблемы илиисточника. Каждая обнаруженная проблема должна быть идентифицирована, описана,проанализирована и разрешена.
Разрешениепроблем проводится на всем протяжении ЖЦ ПП.
1.2.3Организационные процессы жизненного цикла АИС
Основнойцелью организационных процессов является организация процесса разработкинадежного, полностью удовлетворяющего требованиям заказчика программногопродукта в установленные договором сроки и управление этим процессом. Корганизационным относятся процессы управления, создания инфраструктуры,усовершенствования, обучения.
Процессуправления проектами состоит из действий и задач, которые могут выполнятьсялюбой стороной, управляющей своими процессами. Данная сторона (менеджер)отвечает за управление за управление выпуска продукта, проектом и задачамисоответствующих процессов, таких как приобретение, поставка, разработка,эксплуатация, сопровождение и др.
Процесссоздания инфраструктуры охватывает выбор и поддержку (сопровождение)технологии, стандартов и инструментальных средств, выбор и установку аппаратныхи программных средств, используемых для разработки, эксплуатации исопровождения ПП.
Процессусовершенствования предусматривает оценку, измерение, контроль,усовершенствование процессов ЖЦ ПП.
Усовершенствованиепроцессов ЖЦ ПП направлено на повышение производительности труда всехучаствующих в них специалистов за счет совершенствования используемойтехнологии, методов управления, выбора инструментальных средств и обученияперсонала.
Процессобучения охватывает первоначальное обучение и последующее повышение квалификацииперсонала. Основные процессы в значительной степени зависят от уровня знаний иквалификации персонала.
Дляэтого процесса должны быть запланированы необходимые ресурсы и техническиесредства автоматизации.
1.3Модели жизненного цикла АИС
Модельжизненного цикла — структура, определяющаяпоследовательность выполнения и взаимосвязи процессов, действий и задач,выполняемых на протяжении ЖЦ.
Наибольшеераспространение получили две основные модели ЖЦ:
· каскаднаямодель (70-85 гг.);
· спиральнаямодель (86-90 гг.).
1.3.1Каскадная модель
Каскадныйспособ- разбиение всей разработки на этапы, причем переход с одного этапа наследующий происходит только после того, как будет полностью завершена работа натекущем (рис.2).
Положительныестороны применения каскадного подхода:
· накаждом этапе формируется законченный набор проектной документации, отвечающийкритериям полноты и согласованности;
· выполняемыев логичной последовательности этапы работ позволяют планировать срокизавершения всех работ и соответствующие затраты.
Каскадныйподход хорошо зарекомендовал себя при построении информационных систем, длякоторых в самом начале разработки можно достаточно точно и полно сформулироватьвсе требования. В эту категорию попадают сложные расчетные системы, системыреального времени и другие подобные задачи.
/>

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

/>

Рис.3Реальный процесс создания ИС на базе каскадной модели
Одноиз использовавшихся в западной литературе названий такой схемы организацииработ: «водопадная модель» (waterfall model).
Основнымнедостатком каскадного подхода является существенное запаздывание с получениемрезультатов. Модели (как функциональные, так и информационные)автоматизируемого объекта могут устареть одновременно с их утверждением. Другойнедостаток — такое проектирование информационной системы ведет к примитивнойавтоматизации (по сути — «механизации») существующих производственныхдействий работников.
1.3.2Спиральная модель
Вспиральной модели жизненного цикла (рис.4) делается упор на начальные этапы ЖЦ:анализ и проектирование. Реализуемость технических решений проверяется путемсоздания прототипов.

/> 
Рис4. Спиральная модель
Каждыйвиток спирали соответствует созданию нового фрагмента или версии информационнойсистемы, на нем уточняются цели и характеристики проекта, определяется егокачество и планируются работы следующего витка спирали. Один виток спирали приэтом представляет собой законченный проектный цикл по типу каскадной схемы.Такой подход назывался также «Продолжающимся проектированием».Позднее в проектный цикл дополнительно стали включать стадии разработки иопробования прототипа системы. Это называлось: «быстроепрототипирование», rapid prototyping approach или «fast-track».
Однакоприменение таких методов наряду с быстрым эффектом дает снижение управляемостипроектом в целом и стыкуемости различных фрагментов информационной системы.Основная проблема спирального цикла — определение момента перехода на следующийэтап. Переход осуществляется в соответствии с планом, даже если не всязапланированная работа закончена. План составляется на основе статистическихданных, полученных в предыдущих проектах, и личного опыта разработчиков.

ГЛАВА2. CASE-технологии
2.1Основы методологии проектирования автоматизированных систем на основеCASE-технологий
Возрастающаясложность современных автоматизированных систем управления и повышениетребовательности к ним обуславливает применение эффективных технологий созданияи сопровождения автоматизированных систем в течение всего жизненного цикла.Такие технологии, базирующиеся на методологиях подготовки информационных системи соответствующих комплексах интегрированных инструментальных средств, а такжеориентированные на поддержку полного жизненного цикла автоматизированнойсистемы или его основных этапов, получили название CASE-технологий иCASE-средств.
Дляуспешной реализации проекта автоматизированной системы должны быть построеныполные и непротиворечивые, функциональные и информационные модели системыуправления. Накопленный опыт проектирования указанных моделей показывает, чтоэто логически сложная, трудоемкая и длительная по времени работа, требующаявысокой квалификации участвующих в ней специалистов. Однако во многих случаяхпроектирование автоматизированной системы выполняется в основном на интуитивномуровне с применением неформальных методов, основанных на искусстве,практическом опыте и экспертных оценках. Кроме того, в процессе создания ифункционирования АС информационные потребности пользователей могут изменятьсяили уточняться, что еще более усложняет разработку и сопровождениеавтоматизированных систем управления. От перечисленных недостатков в наибольшейстепени свободны подходы, основанные на программно-технических средствахспециального класса — CASE-средствах, реализующих CASE-технологии создания исопровождения АС.
Подтермином CASE (Computer Aided Software Engineering) понимаются программныесредства, поддерживающие процессы создания и сопровождения автоматизированнойсистемы, включая анализ и формулировку требований, проектирование прикладногопрограммного обеспечения и баз данных, генерацию кода, тестирование,документирование, обеспечение качества, конфигурационное управление иуправление проектом, а также другие процессы. CASE-средства вместе с системнымпрограммным обеспечением и техническими средствами образуют полную средуразработки автоматизированной системы.
Однимиз базовых понятий методологии проектирования автоматизированной системыявляется понятие жизненного цикла ее программного обеспечения.
Жизненныйцикл программного обеспечения — это непрерывный процесс, который начинается смомента принятия решения о необходимости создания программного обеспеченияавтоматизированной системы и заканчивается в момент его полного изъятия изэксплуатации
Структуражизненного цикла программного обеспечения базируется на трех группах процессов:основные процессы жизненного цикла программного обеспечения (приобретение,поставка, разработка, эксплуатация, сопровождение); вспомогательные процессы,обеспечивающие выполнение основных процессов (документирование, управлениеконфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит,решение проблем); организационные процессы (управление проектами, создание инфраструктурыпроекта, определение, оценка и улучшение самого жизненного цикла, обучение).
Разработкаохватывает все работы по созданию ПО и его компонентов (анализ, проектированиеи программирование) в соответствии с заданными требованиями, включая оформлениепроектной и эксплуатационной документации, подготовку материалов, необходимыхдля проверки работоспособности и качества программных проектов, материалов,необходимых для организации обучения персонала, и т.д.
Эксплуатациявключает в себя работы по внедрению компонентов программного обеспечения (конфигурированиебазы данных и рабочих мест пользователей, обеспечение эксплуатационнойдокументацией, проведение обучения персонала и др.), локализацию проблем,возникающих при эксплуатации с устранением причин их возникновения, модификациюпрограммного обеспечения в рамках установленного регламента, подготовкупредложений по совершенствованию, развитию и модернизации системы. Каждыйпроцесс характеризуется определенными задачами и методами их решения, исходнымиданными, полученными на предыдущем этапе, и результатами. Результатами анализа,в частности, являются функциональные модели, информационные модели исоответствующие им диаграммы.
Жизненныйцикл программного обеспечения носит итерационный характер: результатыочередного этапа часто вызывают изменения в проектных решениях, выработанных наболее ранних этапах.
Известнонесколько моделей жизненного цикла программного обеспечения. Под модельюжизненного цикла программного обеспечения понимается структура, определяющаяпоследовательность выполнения и взаимосвязи процессов, действий и задач напротяжении всего цикла. Модель жизненного цикла зависит от спецификиавтоматизированной системы и специфики условий, в которых система создается ифункционирует.
Кнастоящему времени наибольшее распространение получили следующие две основныемодели жизненного цикла: каскадный способ и спиральная модель.
Каскаднаямодель применяется, как правило, для разработки однородных автоматизированныхсистем, представляющих собой единое целое. Ее основной характеристикой являетсяразбиение всей разработки на этапы, причем переход с одного этапа на следующийпроисходит только после того, как будет полностью завершена работа на текущем(рис.1). Каждый этап завершается выпуском полного комплекта документации,достаточной для того, чтобы разработка могла быть продолжена другой командойразработчиков. Преимущества применения каскадного способа заключаются вследующем: на каждом этапе формируется законченный набор проектнойдокументации, отвечающий критериям полноты и согласованности; выполняемые влогичной последовательности этапы работ позволяют планировать сроки завершениявсех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовалсебя при построении автоматизированных систем, для которых в самом началеразработки можно достаточно точно и полно сформулировать все требования, с темчтобы предоставить разработчикам свободу реализовать их технически как можнолучше. В эту категорию попадают сложные расчетные системы, системы реальноговремени и др. В то же время этот подход обладает рядом недостатков, вызванных,прежде всего тем, что реальный процесс создания автоматизированной системы никогдаполностью не укладывается в такую жесткую схему, постоянно возникаетпотребность в возврате к предыдущим этапами уточнении или пересмотре ранеепринятых решений.
Такуютрансформацию каскадной схемы разработки автоматизированной системы можнорассматривать как «моделирование с промежуточным контролем».Межэтапные корректировки обеспечивают большую надежность каскадной модели, хотяи увеличивают весь период разработки. Основным недостатком каскадного подходаявляется существенное запаздывание с получением результатов. Согласованиерезультатов с пользователями производится только в точках, планируемых послезавершения каждого этапа работ, требования к автоматизированной системе «заморожены»в виде технического задания на все время ее создания. Таким образом,пользователи могут вносить свои замечания только после того, как работа надсистемой будет полностью завершена. В случае неточного изложения требований илиих изменения в течение длительного периода создания автоматизированной системы пользователиполучают систему, не удовлетворяющую их потребностям. Модели (какфункциональные, так и информационные) автоматизируемого объекта могут устаретьодновременно с их утверждением. От перечисленных недостатков свободнаспиральная модель разработки автоматизированной системы (рис.3), в которойделается упор на начальные этапы жизненного цикла: анализ и проектирование. Наэтих этапах реализуемость технических решений проверяется путем созданияпрототипов. Каждый виток спирали соответствует созданию фрагмента или версии программногообеспечения, на нем уточняются цели и характеристики проекта, определяется егокачество и планируются работы следующего витка спирали. Таким образом,углубляются и последовательно конкретизируются детали проекта и в результатевыбирается обоснованный вариант, который доводится до реализации. Разработкаитерациями отражает объективно существующий спиральный цикл созданияавтоматизированной системы. Неполное завершение работ на каждом этапе позволяетпереходить на следующий этап, не дожидаясь полного завершения работы натекущем. При итеративном способе разработки недостающую работу можно будетвыполнить на следующей итерации. Главная же задача — как можно быстрее показатьпользователям автоматизированной системы работоспособный продукт, тем самымактивизируя процесс уточнения и дополнения требований. Основная проблемаспирального цикла — определение момента перехода на следующий этап. Для еерешения необходимо ввести временные ограничения на каждый из этапов жизненногоцикла. Переход осуществляется в соответствии с планом, даже если не всязапланированная работа закончена. План составляется на основе статистическихданных, полученных в предыдущих проектах, и личного опыта разработчиковавтоматизированных систем. В рамках спиральной модели жизненного цикла широкоераспространение получил один из подходов к разработке программного обеспечения,известный как методология быстрой разработки приложений RAD (Rapid ApplicationDevelopment). Эта методология включает в себя три составляющие: небольшаякоманда программистов (от 2 до 10 человек); короткий, но тщательнопроработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, прикотором разработчики по мере того, как приложение начинает обретать форму,запрашивают и реализуют в продукте требования, полученные через взаимодействиес заказчиком. Команда разработчиков должна представлять собой группупрофессионалов, имеющих опыт в анализе, проектировании, генерации кода итестировании программного обеспечения с использованием CASE-средств, способныххорошо взаимодействовать с конечными пользователями и трансформировать ихпредложения в рабочие прототипы.
Жизненныйцикл программного обеспечения в соответствии с методологией RAD состоит изчетырех фаз: анализа и планирования требований; проектирования; построения;внедрения.
2.2Фаза анализа и планирования требований
Нафазе анализа и планирования требований пользователи автоматизированной системыопределяют функции, которые она должна выполнять, выделяют наиболееприоритетные из них, требующие проработки в первую очередь, описываютинформационные потребности. Формулирование требований к автоматизированнойсистеме осуществляется в основном силами пользователей под руководствомспециалистов-разработчиков. Ограничивается масштаб проекта автоматизированнойсистемы, устанавливаются временные рамки для каждой из последующих фаз. Крометого, определяется сама возможность реализации проекта в заданных размерахфинансирования, на имеющихся аппаратных средствах и т.д. Результатом этогоэтапа должен быть список расставленных по приоритету функций будущейавтоматизированной системы, а также предварительные функциональные моделиавтоматизированной системы.

2.3Фаза проектирования
Наэтапе проектирования часть пользователей принимает участие в техническомпроектировании системы под руководством специалистов-разработчиков.CASE-средства используются для быстрого получения работающих прототиповприложений. Пользователи, непосредственно взаимодействуя с ними, уточняют идополняют требования к системе, которые не были выявлены на предыдущей фазе.Более подробно рассматриваются процессы системы. Анализируется и принеобходимости корректируется функциональная модель. Каждый процессрассматривается детально. При необходимости для элементарного процессасоздается частичный прототип: экран, диалог, отчет, устраняющий неясности илинеоднозначности. Устанавливаются требования разграничения доступа к данным. Наэтой же фазе происходит определение необходимой документации. После детальногоопределения состава процессов оценивается количество функциональных элементовразрабатываемой системы и принимается решение о разделении автоматизированнойсистемы на подсистемы, поддающиеся реализации одной командой разработчиков заприемлемое для RAD-проектов время (60 — 90 дней). С использованием CASE-средствпроект автоматизированной системы распределяется между различными командами(делится функциональная модель). Результатом данного этапа должны быть: общаяинформационная модель системы; функциональные модели системы в целом иподсистем, реализуемых отдельными командами разработчиков; точно определенные спомощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должныбыть получены с применением тех CASE-средств, которые будут использоваться вдальнейшем при построении системы. Данное требование вызвано тем, что втрадиционном подходе при передаче информации о проекте с этапа на этап нередкопроисходит неконтролируемое искажение данных. Применение единой среды храненияданных о проекте позволяет этого избежать. В отличие от обычных подходов, прикоторых используются специфические средства прототипирования, непредназначенные для построения реальных приложений, а прототипы выбрасываютсяпосле устранения неясностей в проекте автоматизированной системы, в подходе RADкаждый прототип передается будущей системе. Таким образом, на следующую фазупередается более полная и полезная информация.
2.4Фаза построения
Наэтапе построения осуществляется непосредственно сама быстрая подготовкаприложения. При этом разработчики выполняют итеративное построение реальнойавтоматизированной системы управления на основе полученных в предыдущей фаземоделей, а также требований нефункционального характера. Программный кодчастично формируется CASE-средствами автоматически. Конечные пользователи наэтой фазе оценивают получаемые результаты и вносят коррективы, если в процессеразработки система перестает удовлетворять указанным ранее требованиям.Тестирование автоматизированной системы осуществляется в процессе разработки.После окончания работ каждой отдельной команды разработчиков производитсяпостепенная интеграция данной части системы с остальными, формируется полныйпрограммный код, выполняется тестирование совместной работы данной частиприложения, а затем тестирование АС в целом. Завершается физическоепроектирование автоматизированной системы, включающее: определениенеобходимости распределения данных; анализ использования данных; физическоепроектирование базы данных; определение требований к аппаратным ресурсам испособов увеличения производительности, завершение разработки документациипроекта. Результатом данного этапа является готовая автоматизированная система,удовлетворяющая всем согласованным требованиям.
2.5Фаза внедрения
Нафазе внедрения автоматизированной системы производится обучение пользователей ивносятся организационные изменения. Для этого этапа характерно то, чтоодновременно с внедрением новой АС осуществляется работа с существующейсистемой управления до полного внедрения новой. Так как фаза построениядостаточно непродолжительна, планирование и подготовка к внедрению должныначинаться заранее, как правило, на этапе проектирования системы. Приведеннаясхема разработки автоматизированной системы не является окончательной. Возможныразличные варианты, зависящие, например, от начальных условий, в которых ведетсясоздание автоматизированной системы: а) разрабатывается совершенно новаясистема; б) было проведено обследование предприятия и существует модель егодеятельности; в) на предприятии уже существует автоматизированная система, котораяможет быть использована в качестве начального прототипа или должна бытьинтегрирована с вновь разрабатываемой системой управления.

ГЛАВА3. Модели жизненного цикла программного продукта
3.1Определение модели ЖЦ АИС
Подмоделью жизненного цикла разработки программного продукта понимается структура,определяющая последовательность выполнения и взаимосвязи процессов, действий изадач, выполняемых на протяжении жизненного цикла разработки программногопродукта. Наибольшее распространение получили следующие модели жизненного цикларазработки программного продукта (таблица1. Краткие характеристики моделейжизненного цикла АИС): каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модельпрототипирования (prototype model); модель быстрой разработкиприложений, или RAD-модель (RAD-rapid application development model); многопроходнаямодель (incremental model); спиральная модель (spiral model).
Таблица1.Краткие характеристики каждой из перечисленных моделейНазвание характеристики Каскадная модель Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы. Разрабатываемое программное обеспечение не доступно для изменений v-образная модель Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования Модель прототипирования Создается «быстрая» частичная реализация системы до составления окончательных требований. Обеспечивается обратная связь между пользователями и разработчиками в процессе выполнения проекта. Используемые требования не полные Модель быстрой разработки приложений Проектные группы небольшие (3… 7 человек) и составлены из высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 месяцев) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки Многопроходная модель Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки. Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации Спиральная модель Охватывает каскадную модель. Расчленяет фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с программным продуктом на более раннем этапе благодаря прототипам
3.2Каскадная модель
Воднородных информационных системах 1970-х и 1980-х годов прикладные программныепродукты представляли собой единое целое. Для разработки такого типапрограммного продукта применялось каскадная модель, или «водопад».
Каскаднаямодель программного продукта подобна модели автоматизированной системыуправления (см. главу 1, рис.1).
Этотпроцесс носит, как правило, итерационный характер: результаты очередного этапачасто вызывают изменения в проектных решениях, выработанных на более раннихстадиях. Таким образом, постоянно возникает потребность в возврате к предыдущимэтапам и уточнении или пересмотре ранее принятых решений. В результате реальныйпроцесс разработки принимает иной вид (см. глава 1, рис.2)

3.3V-образная модель
Этамодель (рис.5) была разработана как разновидность каскадной модели, в которойособое внимание уделяется верификации и аттестации программного продукта.Модель показывает, что тестирование продукта обсуждается, проектируется ипланируется, начиная с ранних этапов жизненного цикла разработки.
Откаскадной модели v-образная модель унаследовала последовательную структуру, всоответствии с которой каждая последующая фаза начинается только после успешногозавершения предыдущей фазы.
Даннаямодель основана на систематическом подходе к проблеме, для решения которойопределены четыре базовых шага: анализ, проектирование, разработка и обзор. Привыполнении анализа осуществляются планирование проекта и составлениетребований. Проектирование разделяется на высокоуровневое и детальное(низкоуровневое). Разработка включает в себя кодирование, обзор – различныевиды тестирования.
Намодели хорошо просматриваются взаимосвязи между аналитическими фазами и фазамипроектирования, которые предшествуют кодированию и тестированию. Штриховыестрелки показывают, что эти фазы надо рассматривать параллельно.
Модельвключает в себя следующие фазы:
Составлениетребований к проекту и планирование – определяются системные требования ивыполняется планирование работ;
Составлениетребований к продукту и их анализ – составляется полная спецификация требованийк программному продукту;
Высокоуровневоепроектирование – определяется структура программного обеспечения, взаимосвязимежду основными его компонентами и реализуемые ими функции;
Детальноепроектирование – определяется алгоритм работы каждого компонента;
Кодирование– выполняется преобразование алгоритмов в готовое программное обеспечение;
Модульноетестирование – выполняется проверка каждого компонента или модуля программногопродукта;
Интеграционноетестирование – осуществляются интеграция программного продукта и еготестирование;
Системноетестирование – выполняется проверка функционирования программного продукта послепомещения его в аппаратную среду в соответствии со спецификацией требований;
Эксплуатацияи сопровождение – запуск программного продукта в производство. На этой фазе впрограммный продукт могут вноситься поправки и может выполняться егомодернизация.
/>

Рис.5V-образная модель

Преимуществаv-образной модели:
1)Большая роль придается верификации и аттестации программного продукта, начинаяс ранних стадий его разработки, все действия планируются;
2)Предполагаются аттестация и верификация не только самого программного продукта,но и всех полученных внутренних и внешних данных;
3)Ход выполнения работы может легко отслеживаться, так как завершение каждой фазыявляется контрольной точкой.
Кромеперечисленных достоинств модель обладает и рядом недостатков:
неучитываются итерации между фазами; нельзя вносить изменения на разных этапахжизненного цикла; тестирование требований происходит слишком поздно, поэтомувнесение изменений влияет на выполнение графика работ.
Даннуюмодель целесообразно использовать при разработке программных продуктов, главнымтребованием для которых является высокая надежность.
3.4Модель прототипирования
/>
Рис.6Модель прототипирования

Модельпрототипитования позволяет создать прототип программного продукта до или втечение этапа составления требований к программному продукту. Потенциальныепользователи работают с этим прототипом, определяя его сильные и слабыестороны, о результатах сообщают разработчикам программного продукта. Такимобразом, обеспечивается обратная связь между пользователями и разработчиками,которая используется для изменения или корректировки спецификации требований кпрограммному продукту. В результате такой работы продукт будет отражатьреальные потребности пользователей.
Жизненныйцикл разработки программного продукта начинается с разработки плана проекта,затем выполняется быстрый анализ, после чего создаются база данных,пользовательский интерфейс и выполняется разработка необходимых функций. Врезультате этой работы получается документ, содержащий частичную спецификациютребований к программному продукту. Данный документ в дальнейшем является основойдля итерационного цикла быстрого прототипирования.
Врезультате прототипирования разработчик демонстрирует пользователям готовыйпрототип, а пользователи оценивают его функционирование. После этогоопределяются проблемы, над устранением которых совместно работают пользователии разработчики. Этот процесс продолжается до тех пор, пока пользователи небудут удовлетворены степенью соответствия программного продукта, поставленнымперед ним требованиям. Затем прототип демонстрируют пользователям с целью полученияпредложений по его усовершенствованию, которые включаются в последовательныеитерации до тех пор, пока рабочая модель не окажется удовлетворительной. Послеэтого получают от пользователей официальное одобрение (утверждение)функциональных возможностей прототипа и выполняют его окончательноепреобразование в готовый программный продукт.
Модельпротипирования обладает целым рядом преимуществ:
1)        Взаимодействиезаказчика с разрабатываемой системой начинается на раннем этапе;
2)        Благодаряреакции заказчика на прототип сводится к минимуму число неточностей втребованиях;
3)        Снижаетсявероятность возникновения путаницы, искажения информации или недоразумений приопределении требований к программному прдукту, что приводит к созданию болеекачественного программного продукта;
4)        Впроцессе разработки всегда можно учесть новые, даже неожиданные требованиязаказчика;
5)        Прототиппредставляет собой формальную спецификацию, воплощенную в программный продукт;
6)        Прототиппозволяет очень гибко выполнять проектирование и разработку, включая несколькоитераций на всех фазах жизненного цикла разработки;
7)        Заказчиквсегда видит прогресс в процессе разработки программного продукта;
8)        Возможностьвозникновения противоречий между разработчиками и заказчиками сведена к минимуму;
9)        Уменьшаетсячисло доработок, что снижает стоимость разработки: возникающие проблемырешаются на ранних стадиях, что резко сокращает расходы на их устранение;заказчики принимают участие в процессе разработки на протяжении всегожизненного цикла и в конечном итоге в большей степени довольны результатомработы.
Кромеуказанных достоинств модели прототипирования присущ и целый ряд недостатков:
1)        Решениесложных задач может отодвигаться на будущее;
2)        Заказчикможет предпочесть получить прототип, а не законченную полную версиюпрограммного продукта;
3)        Прототипированиеможет неоправданно затянуться;
4)        Передначалом работы неизвестно, сколько итераций придется выполнить.
Модельпрототипирования рекомендуется применять в следующих случаях:
1)        Требованияк программному продукту заранее неизвестны;
2)        Требованияне постоянны или неудачно сформулированы;
3)        Требованиянеобходимо уточнить;
4)        Нужнапроверка концепции;
5)        Существуетпотребность в пользовательском интерфейсе;
6)        Выполняетсяновая, не имеющая аналогов разработка;
7)        Разработчикине уверены в том, какое решение следует выбрать.
3.5Модель быстрой разработки приложений (RAD-модель)
ВRAD-модели (рис.7) конечныйпользователь играет решающую роль. В тесном взаимодействии с разработчиками онучаствует в формировании требований и апробации их на работающих прототипах.Таким образом, в начале жизненного цикла на конечного пользователя выпадаетбольшая часть работы, но в результате этого создаваемая система формируетсяболее быстро.
Втрадиционном жизненном цикле разработки большую часть работы составляютпрограммирование и тестирование. При автоматизации программирования и повторномиспользовании кода, применяемых в RAD-модели, большую часть работысоставляют планирование и проектирование.
Нарисунке (рис.7), поясняющем принцип RAD-модели, указаны этапы процессаразработки и отображено участие заказчиков (штриховая линия) на каждом из них.
Модельвключает в себя следующие фазы:
Составлениетребований и планирование — осуществляются с использованием, так называемогометода совместного планирования требований (планирование работ по созданиюпрограммного продукта и составление требований к программному продуктувыполняются одновременно), который заключается в структурном анализе иобсуждении решаемых задач;
Описаниепользователя – проектирование программного продукта, выполняемое принепосредственном участии заказчика;
Создание– детальное проектирование, кодирование и тестирование программного продукта, атакже поставка его заказчику;
Сопровождение– приемочные испытания, установка программного продукта и обучениепользователей.
Модельобладает следующими достоинствами:
1)        Использованиесовременных инструментальных средств позволяет сократить время цикларазработки;
2)        Привлечениек работе заказчика сводит к минимуму риск того, что он останется недоволенготовым программным продуктом;
3)        Повторноиспользуются компоненты уже существующих программ.
Вто же время ей присущи и недостатки:
1)        Еслизаказчики не могут постоянно участвовать в процессе разработки, то это можетнегативно сказаться на программном продукте;
2)        Дляработы нужны высококвалифицированные кадры, умеющие пользоваться современнымиинструментальными средствами;
3)        Существуетриск, что работа над программным продуктом никогда не будет завершена, так какможет быть зациклена, поэтому всегда надо вовремя остановиться.
РассмотреннуюRAD-модель можноприменять при разработке программных продуктов, которые хорошо поддаютсямоделированию, когда требования к программным продуктам хорошо известны, азаказчик может принять непосредственное участие в процессе разработки.

/>

Рис.7Модель быстрой разработки приложений
3.6Многопроходная модель
Многопроходнаямодель (рис.8) – это несколько итераций процесса построения прототипапрограммного продукта с добавлением на каждой следующей итерации новыхфункциональных возможностей или повышением эффективности программного продукта.
Предполагается,что на ранних этапах жизненного цикла разработки (планирование, анализтребований и разработка проекта) выполняется конструирование программногопродукта в целом. Тогда же определяется и число необходимых инкрементов и относящихсяк ним функций. Каждый инкремент затем проходит через оставшиеся фазы жизненногоцикла (кодирование и тестирование). Сначала выполняются конструирование,тестирование и реализация базовых функций, составляющих основу программногопродукта. Последующие итерации направлены на улучшение функциональныхвозможностей программного продукта.
Преимуществамногопроходной модели: в начале разработки требуются средства только дляразработки и реализации основных функций программного продукта; после каждогоинкремента получается функциональный продукт; снижается риск неудачи иизменения требований; улучшается понимание как разработчиками, так ипользователями программного продукта требований для более поздних итераций; инкрементыфункциональных возможностей легко поддаются тестированию.
Недостаткимногопроходной модели: не предусмотрены итерации внутри каждого инкремента;определение полной функциональности должно быть осуществлено в самом начале жизненногоцикла разработки; может возникнуть тенденция оттягивания решения трудных задач;общие затраты на создание программного продукта не будут снижены по сравнению сдругими моделями; обязательным условием является наличие хорошего планированияи проектирования.
Многопроходнаямодель может быть применена, если большинство требований к программномупродукту будут сформулированы заранее, а для выполнения проекта будет выделенбольшой период времени.

/>

Рис.8Многопроходная модель
3.7Спиральная модель
/>
Рис.9Спиральная модель

Дляпреодоления проблем, связанных с использованием многопроходной модели, всередине 1980-х годов была предложена спиральная модель жизненного цикла. Еепринципиальная особенность заключается в том, что прикладной программныйпродукт создается не сразу, как в случае каскадного подхода, а по частям сиспользованием метода прототипирования. Под прототипом понимается действующийпрограммный компонент, реализующий отдельные функции и внешние интерфейсыразрабатываемого программного продукта. Создание прототипов осуществляется занесколько итераций, или витков спирали. Каждая итерация соответствует созданиюфрагмента, или версии программного продукта, на ней уточняются цели ихарактеристики проекта, оценивается качество полученных результатов ипланируется работа следующей итерации. На каждой итерации производитсятщательная оценка риска превышения сроков и стоимости проекта с цельюопределения необходимости выполнения еще одной итерации, степени полноты иточности понимания требований к системе, а также целесообразности прекращенияпроекта. Спиральная модель (рис.9) избавляет пользователей и разработчиковпрограммного продукта от полного и точного формулирования требований к системена начальной стадии, поскольку они уточняются на каждой итерации. Такимобразом, углубляются и последовательно конкретизируются детали проекта и врезультате выбирается обоснованный вариант, который доводится до реализации.
Разработкаитерациями отражает объективно существующий спиральный цикл создания системы,позволяя переходить на следующую стадию, не дожидаясь полного завершения работына текущей стадии, поскольку при итеративном способе разработки недостающуюработу можно выполнить на следующей итерации. Главная задача такой разработки –как можно быстрее показать пользователям системы работоспособный продукт, темсамым активизируя процесс уточнения и дополнения требований.
Спиральнаямодель не исключает использования каскадного подхода на завершающих стадияхпроекта в тех случаях, когда требования к системе оказываются полностьюопределенными.
Основнаяпроблема спирального цикла – определение момента перехода на следующую стадию.Для ее решения необходимо ввести временные ограничения на каждую из стадийжизненного цикла. Переход осуществляется в соответствии с планом, даже если невся запланированная работа закончена. План составляется на основестатистических данных, полученных в предыдущих проектах, и личного опытаразработчиков.
Спиральнаямодель обладает следующими достоинствами: заказчик имеет возможность увидетьразрабатываемый программный продукт на ранних стадиях разработки; заказчикипринимают активное участие в разработке программного продукта; в моделивоплощены преимущества каскадной и многопроходной модели.
Недостаткиспиральной модели: спираль может продолжаться до бесконечности, так как каждаяответная реакция заказчика может породить новый цикл.
Вкачестве модели жизненного цикла разработки программного продукта большоераспространение получила улучшенная спиральная модель, показанная на рис. 10.
/>
Рис.10Улучшенная спиральная модель с указанием вспомогательных процессов

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

Заключение
Вданной курсовой работе я рассмотрел понятия жизненного цикла автоматизированныхинформационных систем и программного продукта.
Работасостоит из трех глав.
Впервой главе рассказывалось о моделях жизненного цикла автоматизированныхинформационных системах.
Жизненныйцикл автоматизированных информационных систем — это непрерывный процесс, которыйначинается с момента принятия решения о необходимости создания ИС изаканчивается в момент ее полного изъятия из эксплуатации.
Модельжизненного цикла — структура, определяющая последовательность выполнения ивзаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ.
Наибольшеераспространение получили две основные модели ЖЦ:
· каскаднаямодель (70-85 гг.);
· спиральнаямодель (86-90 гг.).
Структуражизненного цикла базируется на трех группах процессов:
· основныепроцессы жизненного цикла (приобретение, поставка, разработка, эксплуатация,сопровождение);
· вспомогательныепроцессы (документирование, управление конфигурацией, обеспечение качества,аттестация, аудит, решение проблем);
· организационныепроцессы (управление проектами, создание инфраструктуры проекта, улучшениесамого жизненного цикла, обучение).
Вовторой главе речь шла о CASE-технологиях. CASE-технология — технология,базирующаяся на методологиях подготовки информационных систем и соответствующихкомплексах интегрированных инструментальных средств, а также ориентированная наподдержку полного жизненного цикла автоматизированной системы или его основныхэтапов.
Подтермином CASE(Computer Aided Software Engineering) понимаются программные средства,поддерживающие процессы создания и сопровождения автоматизированной системывключая анализ и формулировку требований, проектирование прикладногопрограммного обеспечения и баз данных, генерацию кода, тестирование,документирование, обеспечение качества, конфигурационное управление иуправление проектом, а также другие процессы. CASE-средства вместе с системнымпрограммным обеспечением и техническими средствами образуют полную средуразработки АС.
Втретьей главе — модели жизненного цикла программного продукта.
Подмоделью жизненного цикла разработки программного продукта понимается структура,определяющая последовательность выполнения и взаимосвязи процессов, действий изадач, выполняемых на протяжении жизненного цикла разработки программногопродукта. Наибольшее распространение получили следующие модели жизненного цикларазработки программного продукта: каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модельпрототипирования (prototype model); модель быстрой разработкиприложений, или RAD-модель (RAD-rapid application development model); многопроходнаямодель (incremental model); спиральная модель (spiral model).

Списокиспользованной литературы
1.     ВендровА.М. Проектирование программного обеспечения экономических информационныхсистем. – М.: Финансы и статистика, 2000. – 352с.
2.     КанерС., Фолк Д., Кен Нгуен Е. Тестирование программного обеспечения: Пер. с англ. –Киев: ДиаСофт, 2000. – 544с.
3.     СоммервиллИ. Инженерия программного обеспечения. – М.: СПБ.: Киев: Изд. дом «Вильямс»,2002. – 624с.
4.     ФридманА.Л. Основы объектно-ориентированной разработки программных систем. – М.:Финансы и статистика, 2000. – 200с.
5.     ГагаринаЛ.Г. Основы технологии и разработки программных продуктов: Учебник – М ФОРУМ –ИНФРА – М. 2006.
6.     СеменовМ.И. Трубилин И.Т., Лойко В.И. Барановская Т.П. Архитектура компьютерных системи сетей Учебное пособие – М Финансы и статистика, 2004. – 320с.
7.     СоветовБ.Я. Цеханковский В.В. Информационные технологии – М Высшая школа, 2003.
8.     Информатика:Учебник под редакцией Макаровой Н.В. – М.: Финансы и статистика., 2005. – 480с.